MySQL优化之CPU和IO

mySQL优化之CPU和IO

决定一个水桶容量的，是最短的一块板子，MySQL也不例外，MySQL服务器的性能受制于整个系统的磁盘大小、可用内存、CPU资源，网络带宽等等，这其中，最常见的两个性能瓶颈因素是CPU和IO资源。

现有的技术，磁盘和内存已经不是系统最重要的瓶颈，将大量的数据集都放到大容量的内存中，以现有的技术是完全可以做到的。当MySQL中的数据以足够快的速度从内存中读取时，CPU的计算能力将会成为系统的瓶颈。

当我们遇到CPU密集型的工作时，CPU的速度越快，那么MySQL服务的性能就越好。同样，CPU的个数越多，那么可以并发的处理的查询个数就越多，也会同样提升MySQL服务器的性能。

那么问题来了，多和快哪个更重要？？？

一般来讲，鱼和熊掌兼得是最好的情况，就是你的CPU又多又快，当然这是不现实的，我们想来看看这两种特点带来的好处：

低延迟---快速响应

毫无疑问，高速的CPU会让查询的时间变短，客户端命令的响应时间也会变短。

高吞吐---并发处理

如果能够同时运行多个查询语句，那么查询的性能一定会得到提升。及时只运行一个查询SQL，多个CPU能够合理的分流MySQL的InnoDB缓冲清理、网络操作等后台任务，也会使得查询的性能更快。

所以，准确的来说，CPU的多和快哪个影响严重，还是取决于你用它来干什么。有些场景可能需要更多的CPU，有些场景可能多个CPU也无法解决，反而更快的CPU优势更明显。举一个例子，例如主从复制，多个CPU对于复制的影响不是特别大，因为主库上的并发复制任务传递到从库之后会被简化成串行任务，这样，从库的CPU即使比主库更多，由于是串行操作，也不会比主库快多少。所以在这种情况下，主库的CPU最好是多个，从而处理并发复制的情况，而从库的CPU最好是性能更佳的，从而能够迅速处理从主库拉取的binlog内容。

另一方面来看，多个CPU的系统在OLTP系统的场景中非常有用，这些系统通常需要并发执行更小的操作，并且是从多个连接发起请求，因此可以在多个CPU上运行，相反的，OLAP系统的场景中，高性能的CPU可能更能派上用场，因为这种情况下，对于CPU的计算分析统计能力要求是极高的。

关于IO，现有的数据库中一般都同时使用顺序IO和随机IO。随机IO从缓存中受益良多，我们设想有这样一个场景，它混合了精确查找和多行范围查找，当它的"热点"数据随机分布的时候，如果我们对这些热数据进行缓存，就可以避免时间代价比较大的磁盘寻址，这无疑会提高数据库的性能，如果没有缓存，从磁盘随机寻址和应用进行交互，那个时间可想而知。相对于随机IO寻址，顺序IO就快的多，缓存对于顺序IO的意义不大。关于顺序IO和随机IO在磁盘和内存中的差异，可以大概用下面的数据了解下：

在磁盘上，随机读和顺序读的差距大概5000量级倍。

在内存中，随机读和顺序读的差距大约在20倍左右。

内存随机访问的速度比磁盘随机访问的速度大概快2500倍。

另外，随机读取查询的行，冗余数据页比较多，而顺序读取的时候，会读取某个页面上的所有数据行，这样更加符合成本效益。如果负担得起，增加内存是解决随机IO读取问题的最好办法。