接着我们将 innodb_max_dirty_pages_pct 下调为 20，观察脏数据情况。由于 InnoDB Buffer Pool 设置为 40G，20% 也就是 8G，此时的压力达不到此阀值，所以调整参数是没有效果的。但业务繁忙时，就可以看到效果，落地频率会增高。
5.9 设置 innodb_io_capacity = 1000修改方法不赘述。
修改之后的 MySQL 配置：
innodb_buffer_pool_size 42949672960
innodb_log_file_size 1342177280
innodb_io_capacity 1000
innodb_max_dirty_pages_pct 20
innodb_adaptive_flushing ON
innodb_write_io_threads 4
innodb_read_io_threads 4
经过以上调整，我们需要的是一个均衡的 IO，给其他进程一些余地。于是把 innodb_io_capacity 设置为 1000，此时可以看到 I/O until 维持在 10% 左右，整个系统的参数趋于稳定。
后续还要做进一步的监控、跟踪、分析和优化。
6、 程序切换之后调优在业务低峰，凌晨 1 点左右，配合研发做了切换。切换之后的主从关系可以查看第五节。
6.1 设置 innodb_max_dirty_pages_pct = 30，innodb_io_capacity = 1500修改方法不赘述。
修改之后的 MySQL 配置：
innodb_buffer_pool_size 42949672960
innodb_log_file_size 1342177280
innodb_io_capacity 1500
innodb_max_dirty_pages_pct 30
innodb_adaptive_flushing ON
innodb_write_io_threads 4
innodb_read_io_threads 4
在 innodb_io_capacity 为 1000，innodb_max_dirty_pages_pct 为 20 的环境下，I/O until 有小幅波动，而且波峰和波谷持续交替，这种情况是不希望看到的。innodbBuffPoolPagesFlushed 比较稳定，但 innodbBuffPoolPagesDirty 持续上涨，没有下降的趋势。故做了如下调整：innodb_max_dirty_pages_pct = 30，innodb_io_capacity = 1500。调整完成后，innodbBuffPoolPagesDirty 趋于稳定，I/O until 也比较稳定。
6.2 设置 innodb_max_dirty_pages_pct = 40，innodb_io_capacity = 2000修改方法不赘述。
修改之后的 MySQL 配置：
innodb_buffer_pool_size 42949672960
innodb_log_file_size 1342177280
innodb_io_capacity 2000
innodb_max_dirty_pages_pct 40
innodb_adaptive_flushing ON
innodb_write_io_threads 4
innodb_read_io_threads 4
针对目前这种 I/O 情况，做了如下调整：innodb_max_dirty_pages_pct = 40，innodb_io_capacity = 2000。
6.3 分析针对以上两个调整，我们通过结合监控数据来分析 I/O 状态。
以下是高速缓冲区的脏页数据情况，如图二：
图二 主库的脏数据情况
InnoDB Dirty pages
以下是脏数据落地的情况，如图三
图三 主库的脏数据落地情况
InnoDB Flushed
28 号早 8 点到下午 7 点，当脏数据上升，也就是在内存中的数据更多，那么落地就会很少，呈现一个平稳的趋势；当脏数据维持不变，也就是脏数据达到了 innodb_max_dirty_pages_pct 的限额（innodb_buffer_pool_size 为 40G，innodb_max_dirty_pages_pct 为 40%，也就是在内存中的脏数据最多为 16G，每个 Page 16K，则 innodbBufferPoolDirtyPages 最大为 1000K），落地就会增多，呈现上升的趋势，所以才会出现上述图片中的曲线。
这是最后的配置：
innodb_buffer_pool_size 42949672960
innodb_log_file_size 1342177280
innodb_io_capacity 2000
innodb_max_dirty_pages_pct 40
innodb_adaptive_flushing ON
innodb_write_io_threads 4
innodb_read_io_threads 4
7、小结此次针对 SSD 以及 MySQL InnoDB 参数优化，总结起来，也就是以下三条：
修改系统 I/O 调度算法；
分析 I/O 情况，动态调整 innodb_io_capacity 和 innodb_max_dirty_pages_pct；
试图调整 innodb_adaptive_flushing，查看效果。
针对 innodb_write_io_threads 和 innodb_read_io_threads 的调优我们目前没有做，我相信调整为 8 或者 16，系统 I/O 性能会更好。
还有，需要注意以下几点：
网络文章介绍的方法有局限性和场景性，不能亲信，不能盲从，做任何调整都要以业务优先。保证业务的平稳运行才是最重要的，性能都是其次；
任何一个调整，都要建立在数据的支撑和严谨的分析基础上，否则都是空谈；
这类调优是非常有意义的，是真正能带来价值的，所以需要多下功夫，并且尽可能地搞明白为什么要这么调整。