问题：
InnoDB 刷脏页刷得比较慢，我的业务会受到影响么？如何进行试验验证？
实验
先宽油建个数据库：
找到这个数据库负责刷脏页的线程号：
我们起一个 gdb（别害怕，本实验没有什么太深的调试技巧），
我们输入以下命令：
前三行命令，允许 gdb 只停下一个线程，而不是停下所有线程。
最后一行 attach，我们让 gdb 管控我们的 MySQL 实例。
经过一堆看不懂的输出，gdb 已经管控了 MySQL 实例，可以输入命令了。
我们先输入 info thread，拿到 MySQL 的线程表，找到负责刷脏页的线程在 gdb 中对应的 ID，是第 13 号线程：
然后我们在 thread 13 上打一个断点（我们为什么知道要在 pc_sleep_if_needed 处打断点呢？留待晚点解释）：
紧接着就会看到 thread 13 停在了断点上，这根线程目前就停下来，不会再进行刷脏页了。
再来看一下各个线程的状态，有 1 号线程和 13 号线程停了下来：
我们将 1 号线程放开：
然后将 gdb 放在一边，现在开始给 MySQL 上压力，还是用我们常用的方法：
不停执行最后一句，会发现 insert 会卡住，观察一下 innodb status：
buffer pool 不再刷脏，无读无写。
数据页总共有 7745 页，而脏页总共有 6586 页，看上去还可以释放一些非脏页出来。
观察 redo log 的状态：
redo log 上一次 checkpoint 到当前的位置，一共有（945661967-869887159 =）75774808 字节（75M）。
而我们的 redo log 总大小有将近 100M（50331648*2 = 100663296 字节）。
看上去 redo log 的空闲也够用。
那么为什么我们不能继续进行业务呢？
我们将 innodb metrics 打开：
观察相关的 metrics：
可以看到 innodb 定义的两条水位线：redo log 尚未 checkpoint 的日志大小（modified age）的水位线，一条异步水位线，一条同步水位线（这两条水位线是 innodb 自动算出来的，不要问为什么合理）
当超过异步水位线时，MySQL 开始调动 IO 尽力刷脏页，但业务仍能正常进行；当超过同步水位线时，将阻塞业务等待刷脏页。
我们的场景下，modified age (=75774808) 刚好超过同步水位线，业务均开始阻塞。
至此，我们通过实验，验证了 innodb 刷脏页慢是会阻塞业务的。
江湖上一直有一个传说，处理 SQL 的线程会在紧急的状况下帮助刷脏页。
本实验中我们只停下了一个线程，大家也就可以验证这个传说不十分靠谱，所有的刷脏页都是通过专门的线程进行，处理 SQL 的线程只能提出刷脏页的需求，而不能直接动手。
扩展知识
知识一
推荐阅读 percona 的文章： https://www.percona.com/blog/2020/01/22/innodb-flushing-in-action-for-percona-server-for-mysql/ 此文分析了 innodb 刷脏页的三个原因：脏页比例高、空闲页数低、adaptive flush(通过计算 redo log 的使用度进行不同程度的刷脏页策略)，并给予了充分的讨论。 在本实验中，我们触发了 adaptive flush 的水位线，业务因此受到了影响。
知识二
知识三
本实验有两处逻辑跳跃：
我们是怎么确定断点位置是 pc_sleep_if_needed 的？ 我们怎么知道 redo log 存在水位线的？ 这两个的答案都一样，就是使用 gdb 观察 MySQL 的堆栈。 可以使用 pstack 或者 gdb，观察 MySQL 在刷脏页线程或者 hang 住时候的堆栈，加以简单分析。
运维建议
建议大家将 InnoDB 刷脏页的三种原因和刷脏程度加入监控系统，可以据此分析业务是否由于这个原因受到影响。