问题：
磁盘 IO 报警，说 IO 饱和了。
那么 MySQL 读写哪个文件慢了？binlog？redo log？还是哪张表？
构造环境：
根据先前的 实验 02，构造环境，模仿 binlog 的磁盘 IO 慢。
实验：
想观察 IO 相关的行为，需启用 performance_schema 的 instrument（生产者）和 consumer（消费者）。将 performance_schema 的配置重置为默认配置，IO 相关的 instrument（生产者）在默认配置里开启。
启用 waits 相关的 consumer（消费者）
将已记录的性能数据清零
向 MySQL 施加压力
在另一个 session 中，观察最近的 IO 行为。
可以看到 binlog 的刷盘 IO 明显比其他操作慢，符合我们构造的实验场景。这样我们就快速定位了哪个文件的 IO 变慢了。有了线程号，我们还可以定位其对应的操作：
结论：
我们通过 sys.x$latest_file_io，找到最近的 IO 操作的记录，进行了排序。
需注意：
1. 这里不用 sys.latest_file_io 的原因是无法对操作延迟进行排序。
以 sys 中, 以 x$ 开头的视图，是原始数据。
不以 x$ 开头的视图，是给人类看的视图（比如时间显示会带单位，显示成 123 ns）。
2. sys.x l a t e s t f i l e i o 视 图 涉 及 到 两 张 表 ： ‘ p e r f o r m a n c e s c h e m a ‘ . ‘ e v e n t s w a i t s h i s t o r y l o n g ‘ 和 ‘ p e r f o r m a n c e s c h e m a ‘ . ‘ t h r e a d s ‘ 如 果 某 个 线 程 退 出 ， 就 不 会 出 现 在 s y s . x latest_file_io 视图涉及到两张表：`performance_schema`. `events_waits_history_long` 和 `performance_schema`. `threads` 如果某个线程退出，就不会出现在 sys.x latestfileio视图涉及到两张表：‘performanceschema‘.‘eventswaitshistorylong‘和‘performanceschema‘.‘threads‘如果某个线程退出，就不会出现在sys.xlatest_file_io 视图。所以 sys.x$latest_file_io 不是"最近的 IO 操作记录"，而是"当前活跃线程的最近的 IO 操作记录"。
380
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
