生产案例：MySQL服务器IO告警会自动重启

背景

有朋友找说他们MySQL数据库每天会自动重启一次，版本MySQL5.7.28，服务器windows server2012，没有备份，没有主从，没有开启binlog，里面有分区表。

思路：

首先就是查看error日志，发现里面没有error错误，只有大量的如下告警：

InnoDB: page_cleaner: 1000ms intended loop took 15755ms. The settings might not be optimal. (flushed=7328 and evicted=0, during the time.)

分析一般出现这种告警是因为IO压力告警了，因为日志里缓存脏数据刷新磁盘是1秒也就是日志的1000毫秒，但是他延迟15秒，所以IO写有告警，首先不确定是什么错误导致重启，就来把这告警解决了。

预估他们某个时间段会有大量的事务写，所以先从数据库层面调一下参数。

innodb_lru_scan_depth 默认1024 调小256

innodb_io_capcity 默认200 调大1000

跟IO相关的参数解释：

该告警意味着MySQL实例按照目前IO相关的参数配置的前提下，存在着IO写入性能上的瓶颈，配置参数与IO处理能力不匹配。连续大批量写入数据造成的，很有可能是checkpoint刷新脏页造成IO不足的警告。
page_cleaner超时只是果，而不是因，一个果可能是有不同的因造成的，具体原因在哪里？
逐步反推这个过程：单次刷新内存数据到磁盘的数量过大<----LRU刷新或者脏页刷刷新<------大批量读写数据（LRU）或者删除出数据（delete，drop等等））。
另外一个原因（删除数据造成的page_cleaner超时）
innodb_lru_scan_depth        = 1024, 256 可以调节的值，
innodb_buffer_pool_instances = 1, 8 可以调节的值，buffer pool大的话建议1就可以了
innodb_io_capcity            = 100, 200 or 1000 
innodb_page_cleaners         = 1, 4 or 8
innodb_io_capacity 决定刷新脏页的数据量，默认1024，IO不行支持不了那么多可以改小点256
innodb_max_dirty_pages_pct 默认75% 已经最优不用调，表示到这个值了会刷新部分脏页到磁盘
innodb_lru_scan_depth lru列表中保持空闲page的数据量，如果低于这个数量，则按照LRU的原则刷新脏页到磁盘。
innodb_log_file_size ：该参数决定着mysql事务日志文件（ib_logfile0）的大小；设置太小会频繁的切换日志，触发checkpoint，造成频繁写IO，设置太大能提高IO，但是有数据库当季恢复久风险，可以保留一个小时的日志量
innodb_log_buffer_size 与上面差不多
innodb_log_files_in_group 默认两组日志切换
innodb_flush_log_at_trx_commit 0每次提交写入log buffer 然后再每秒刷新到文件，宕机就会丢失上一秒事务 1最安全，提交时刷新到buffer和磁盘，大量IO 2每次commit时，事务日志写进了innodb  log buffer，并同时接着写进os cache, 也就是说每次commit，事务日志写进了os cache中， 然后每秒从os cache刷新到ib_logfile(也就是刷新到了磁盘）只有 操作系统断电才会丢失上一秒事务