mysql中的低负载_Mysql高负载（自用）

笔者最近遇到一个问题，在设备供应厂家做完动力监控的服务器部署时，发现监控告警的太慢，不够及时。于是向厂家反馈这个问题，估计厂家也是图方便省心直接将读取Mysql数据库(innodb引擎)的周期从15秒减小到6秒，这下可好，监控服务器更加卡得要死！

经过沟通发现以下几个问题：

问题1：瞬时写入数据量过大。

软件设计不合理，在监控服务器上面得程序将读取到所有的数据每隔一定周期一起写入数据库，瞬间数据量过于庞大。下图是数据写入数据库时，磁盘IO脉冲式增加，特别是减少数据读取周期为6秒时，磁盘IO一直保持在100%，造成监控服务器十分卡顿。

解决办法：

软件上提出建议将程序功能分模块(采集器分类、设备分类或者等级分类)写入数据库，数据库中tables较多，分别写入可降低磁盘IO。

终端读取数据库的间隔适当加长，不和写操作争抢资源。

硬件上可考虑更换固态硬盘来提交读写速率。

运行时磁盘IO状态

只读锁(flush tables with read lock)后磁盘IO正常，开启写(unlock tables)后，磁盘IO脉冲式增加。说明磁盘IO增加的原因是数据库写造成的，那么就需要在写操作上优化。

读锁后磁盘IO正常，开启写后磁盘IO脉冲式增加

问题2：二进制日志文件mysqlbinlog过大

每天数据产生17G的二进制日志文件mysqlbinlog，磁盘快满了。

解决办法：对于监控数据来说，其实没有必要保存改变数据库信息的语句。 expire-logs-days，设置清除log文件的天数。或者直接不需要，在my.ini文件中直接关闭，也可降低磁盘IO。

; binary logging - not required for slaves, but recommended

;log-bin=mysql-bin

问题3：数据库没有经过调优

Mysql数据库没有经过调优。笔者虽不是DBA，但是针对具体问题，结合以前得知识(请参考数据库DB文集)和网络资料，分享一下自己的分析解决思路。

影响数据库最大的性能问题就是磁盘IO，为了提升数据库的IOPS，可以使用SSD或者PCIE-SSD高速磁盘。内存方面也很重要，内存可以缓存热点数据和存储引擎文件，避免产生过多的物理IO，可以增加物理内存来提高数据库的并发和读写性能。

接下里就是主要针对磁盘IO过高时，Mysql数据库参数应该怎么调优？

1、Innodb_buffer_pool_size。作用是缓存innodb表的数据信息，可以设置为物理内存的50-80%。

2、innodb_flush_log_trx_commit和。参数是redo log刷新的参数，默认是1，即在每个事务提交时，InnoDB立即将缓存中的redo日志回写到日志文件，并调用操作系统fsync刷新IO缓存。可以设置为2，即是每个事务提交时，InnoDB立即将缓存中的redo日志回写到日志文件，但并不马上调用fsync来刷新IO缓存，而是每秒只做一次磁盘IO缓存刷新操作。参数为0时，在提交事务时，InnoDB不会立即触发将缓存日志写到磁盘文件的操作，而是每秒触发一次缓存日志回写磁盘操作，并调用操作系统fsync刷新IO缓存。修改为2或者0时，可以节省IO资源，但是在崩溃或断电的时候会丢失最后一秒的数据，但对于监控数据来说没啥影响。

设为是最安全的，但性能也是最差的(相对其他两个参数而言，但不是不能接受)。如果对数据一致性和完整性要求不高，完全可以设为2，如果只要求性能，例如高并发写的日志服务器，设置为0来获得更高性能。

3、sync_binlog。binlog刷新的参数，默认是1。和参数innodb_flush_log_trx_commit组成数据库的双一，可以保证主从架构中数据的一致性。在监控系统中，binlog关闭了。

4、innodb_max_dirty_pages_pct。脏页占Innodb_buffer_pool的比例，，超过时触发刷脏页到磁盘，建议25%-50%。

5、innodb_io_capacity。innodb后台进程中最大的IO性能指标，影响刷脏页和插入缓冲的数量，默认200。高转速磁盘下可以适当提高该参数。SSD磁盘配置可以调整为5000-20000，PCIE-SSD高速磁盘可以调整得更高(50000)。

6、innodb_data_file_path = ibdata1:1G:autoextend。innodb表空间不要使用默认得10MB，可以调整为1G，防止高并发下数据库受影响。

7、gerenal log。全量日志建议关闭，默认是关闭的，否则日志文件会越来越大，影响性能。