书接上回，模拟完磁盘IO报警，那么 MySQL 读写哪个文件慢了？binlog？redo log？还是哪张表？
实验环境：Rocky Linux 8
镜像：Rocky-8.6-x86_64-dvd.iso
根据先前的实验 ，构造环境，模仿 binlog 的磁盘 IO 慢。
1.观察IO相关行为
将 performance_schema 的配置重置为默认配置，IO 相关的 instrument（生产者）在默认配置里开启。
mysql> CALL sys.ps_setup_reset_to_default(FALSE);
Query OK, 0 rows affected (0.01 sec)
启用 waits 相关的 consumer（消费者）
mysql> CALL sys.ps_setup_enable_consumer ('waits');
+---------------------+
| summary |
+---------------------+
| Enabled 3 consumers |
+---------------------+
1 row in set (0.00 sec)Query OK, 0 rows affected (0.00 sec)
将已记录的性能数据清零
mysql> CALL sys.ps_truncate_all_tables(FALSE);
+---------------------+
| summary |
+---------------------+
| Truncated 49 tables |
+---------------------+
1 row in set (0.08 sec)Query OK, 0 rows affected (0.08 sec)
2.开始IO测试
[root@localhost ~]mysqlslap --user=root --password=lmx --host=127.0.0.1 \
--concurrency=50 --iterations=2000 --query="insert into a1 values()" \
--create="create table a1(b int primary key AUTO_INCREMENT)"
mysqlslap: [Warning] Using a password on the command line interface can be insecure.
在开一个窗口，观察最近的 IO 行为。
select *, latency/1000/1000/1000 as latency_ms from x$latest_file_io
order by latency desc limit 20;
#在sys库下
可以看到 binlog 的刷盘 IO 明显比其他操作慢，符合我们构造的实验场景。这样我们就快速定位了哪个文件的 IO 变慢了。有了线程号，我们还可以定位其对应的操作：
select * from performance_schema.threads where PROCESSLIST ID-36881 \G
3.结论
我们通过 sys.x$latest_file_io，找到最近的 IO 操作的记录，进行了排序。
需注意：
1 这里不用 sys.latest_file_io 的原因是无法对操作延迟进行排序。
以 sys 中, 以 x$ 开头的视图，是原始数据。不以 x$ 开头的视图，是给人类看的视图（比如时间显示会带单位，显示成 123 ns）。
2 sys.x$latest_file_io 视图涉及到两张表：performance_schema. events_waits_history_long 和 performance_schema. threads 如果某个线程退出，就不会出现在 sys.x$latest_file_io 视图。所以 sys.x$latest_file_io 不是"最近的 IO 操作记录"，而是"当前活跃线程的最近的 IO 操作记录"。