影响MySQL性能的硬件因素

好买网    www.goodmai.com      IT技术交易平台

第一部分 磁盘I/O与内存

影响MySQL InnoDB引擎性能的最主要因素就是磁盘I/O，目前磁盘都是机械方式运作的，主要体现在读写前寻找此道的过程中。磁盘自带的读写缓存大小，对于磁盘的读写速度至关重要。读写速度快的磁盘，通常都带有较大的读写缓存。磁盘的寻道过程是机械方式。决定了其随机读写速度将明显低于顺序读写。在多进程或多线程并发读取磁盘的情况下，每次执行读写操作，磁盘可能存在较大的偏移，磁盘寻址时间加大，将会导致磁盘I/O性能急剧下降。从很多新特性来看，几乎都是围绕着如何充分利用内存，如何减少磁盘I/O来展开的，例如：innodb_io_capactiy参数，可以加大每秒刷新脏页的数量。因此在单块磁盘遇到了I/O瓶颈时，可以把磁盘升级为RAID或SSD固体硬盘来提升性能，SSD固态硬盘的特点是：不用磁头读取数据，寻道时间几乎为0，快速的随机读写，延迟极小，当然价格也很昂贵。目前在生产环境中主要采用RAID10、RAID5，对于数据读写操作频繁的表或数据库，可以适当采用将数据分级存储在SSD固态电子硬盘中的方式，速度会得到较大提升！

在Buffer_Pool缓冲池中，涉及的参数为innodb_buffer_pool_size，它是InnoDB引擎中最重要的参数之一，对InnoDB的性能有决定性的影响。默认的设置只有8MB，使用默认值时InnoDB的性能很差，远远不能满足生产的需求。在只有InnoDB存储引擎的数据库服务器上面，可以将其设置为60%~80%的内存。如果你有足够的内存，可以将数据量全部放入内存，这时才能达到最佳性能。内存是影响MySQL服务器性能好坏的最关键指标，而MySQL的InnoDB引擎中的innodb_buffer_pool_size参数可以设置为物理内存的70%~80%。因为把数据放在内存中比存放在磁盘中要快得多，何乐而不为呢？但是话又说回来，也不能随意分配内存，要根据系统的整体情况来做个判断。Linux服务器中的内存主要被四类事务所消耗：内核、文件系统高速缓存、应用程序进程、特定预留的共享内存。

上面两个因素是从硬件角度上看的，也就是说因为业务的增长，致使硬件遇到了瓶颈，而另一种常见的情况是，大量的慢SQL是导致性能低下的首要“元凶”，在这种情况下，优化慢SQL是关键，在上线前，应有专门的DBA来审核开发写的SQL语句，通过这样的审核，可避免线上遇到问题。优化一条SQL语句在某种情况下，比增添1条内存管用得多。例如：

第一部分 磁盘I/O与内存

影响MySQL InnoDB引擎性能的最主要因素就是磁盘I/O，目前磁盘都是机械方式运作的，主要体现在读写前寻找此道的过程中。磁盘自带的读写缓存大小，对于磁盘的读写速度至关重要。读写速度快的磁盘，通常都带有较大的读写缓存。磁盘的寻道过程是机械方式。决定了其随机读写速度将明显低于顺序读写。在多进程或多线程并发读取磁盘的情况下，每次执行读写操作，磁盘可能存在较大的偏移，磁盘寻址时间加大，将会导致磁盘I/O性能急剧下降。从很多新特性来看，几乎都是围绕着如何充分利用内存，如何减少磁盘I/O来展开的，例如：innodb_io_capactiy参数，可以加大每秒刷新脏页的数量。因此在单块磁盘遇到了I/O瓶颈时，可以把磁盘升级为RAID或SSD固体硬盘来提升性能，SSD固态硬盘的特点是：不用磁头读取数据，寻道时间几乎为0，快速的随机读写，延迟极小，当然价格也很昂贵。目前在生产环境中主要采用RAID10、RAID5，对于数据读写操作频繁的表或数据库，可以适当采用将数据分级存储在SSD固态电子硬盘中的方式，速度会得到较大提升！

在Buffer_Pool缓冲池中，涉及的参数为innodb_buffer_pool_size，它是InnoDB引擎中最重要的参数之一，对InnoDB的性能有决定性的影响。默认的设置只有8MB，使用默认值时InnoDB的性能很差，远远不能满足生产的需求。在只有InnoDB存储引擎的数据库服务器上面，可以将其设置为60%~80%的内存。如果你有足够的内存，可以将数据量全部放入内存，这时才能达到最佳性能。内存是影响MySQL服务器性能好坏的最关键指标，而MySQL的InnoDB引擎中的innodb_buffer_pool_size参数可以设置为物理内存的70%~80%。因为把数据放在内存中比存放在磁盘中要快得多，何乐而不为呢？但是话又说回来，也不能随意分配内存，要根据系统的整体情况来做个判断。Linux服务器中的内存主要被四类事务所消耗：内核、文件系统高速缓存、应用程序进程、特定预留的共享内存。

上面两个因素是从硬件角度上看的，也就是说因为业务的增长，致使硬件遇到了瓶颈，而另一种常见的情况是，大量的慢SQL是导致性能低下的首要“元凶”，在这种情况下，优化慢SQL是关键，在上线前，应有专门的DBA来审核开发写的SQL语句，通过这样的审核，可避免线上遇到问题。优化一条SQL语句在某种情况下，比增添1条内存管用得多。例如：

SELECT * FROM t WHERE id>='10' and id<='30';

这条语句乍一看没什么问题，可运行后马上就记录在慢日志里了，这是怎么回事？细心的DBA可能会发现id是int数值整型，由于加上了引号（''），转化为字符型，于是造成了不能使用索引。

而如何分辨是硬件性能上遇到了瓶颈，还是SQL自身的问题？这个就要通过日常的监控来确定了，比如，每天早上发一封慢日志邮件来查看SQL的情况，自然就对业务的SQL较为熟悉，再对比最近二到三天内邮件上的慢SQL，这样很容易找出存在的问题。假设某个SQL在昨天慢日志里没有出现，而在今天却出现了，那么尝试着在备机上运行下，如果很快就得到了执行结果，那么就不是SQL的问题，而是业务增长造成的硬件瓶颈。

第二部分 系统性能评估标准 

对于MySQLDBA来说，系统性能的实时检测和评估是其需要长期面对的问题，包括上线前各方面的性能测试及上线后整体性能评估，以及随时掌握系统的运行状态是否健康等，对于数据库服务器而言这些工作非常重要。

在操作系统层面影响Linux服务器性能的因素主要就是服务器CPU、内存、磁盘I/O、网络I/O，以及Linux系统本身的内核。

3.1 CPU性能指标

从整体上来说，CPU性能指标比较多，因为CPU处理的事物也比较多。常见的指标如下：

CPU使用率：这可能是最直接的指标了，它表示每个处理器的整体使用率。如果在持续一段时间里CPU的使用率大于80%，这就可能表明CPU出现了瓶颈。

%us：应用程序（用户空间）表示用户应用进程所花费的CPU百分比，包括Nice时间。如果用户时间值很高，表明系统正在执行实际的工作。

%sy：系统（内核空间）表示内核操作所花费的CPU百分比，包括中断。系统时间值持续很高表明网络或驱动器堆栈可能存在瓶颈。通常，系统只会花费很少时间在内核时间上。

%wa：I/O等待 等待I/O操作所需的CPU时间总和，系统不应该花费过多的时间等待I/O操作，否则你应该检查一下I/O子系统各方面的性能。

%id：空闲时间 表示CPU空闲的百分比。这个值越大表明系统CPU的负荷越小。

%ni：Nice时间 表示花费在执行renicing（改变进程的执行顺序和优先级）进程的CPU百分比。

3.2 内存性能指标

空闲内存与其他操作系统相比，在Linux系统中不必过分在意空闲内存值。因为Linux内核会将大量未使用的内存分配给文件系统来缓存数据。

交换空间使用 这个值表示已使用的交换空间大小，相当于Windows系统中的虚拟内存。交换空间的使用只能告诉你Linux在管理内存上是多么的有效。要想确定内存是否存在瓶颈，需要用到SwapIn/Out。如果SwapIn/Out长时间保持在每秒钟超过200~300页，可能表示内存存在瓶颈。

3.3 磁盘性能指标

磁盘I/O等待 CPU在等待I/O操作时所花费的时间。如果这个值持续很高，很可能表示I/O存在瓶颈。

队列平均长度 I/O请求的数量。通常硬盘队列值为2~3时最佳；过高可能表示硬盘I/O存在瓶颈。

平均等待时间 I/O请求服务所花费的平均时间。等待时间包括实际I/O操作的时间和在I/O队列中等待的时间。单位为毫秒（ms）。

每秒钟传输的数量 表示每秒钟执行了多少次I/O操作（包括读取和写入）。与每秒钟传输字节数结合可以帮助确定系统平均传输值大小。平均传输值通常要与硬盘子系统的条带大小一致。

每秒钟读写块的数量 这个指标表示每秒钟读写块的数量，在2.6.XX内核中块的大小为1024字节，早期的内核可以有不同的块大小，其范围可从512字节到4KB。

每秒钟读写字节的数量 表示块设备读写的实际数据的数量，单位为KB。