sys Schema

做的事：用sys schema一行查出真实的I/O分类统计

代码SELECT * FROM sys.io_global_by_wait_by_bytes LIMIT 3;

验证：真实按文件类型分类好的I/O统计，直接能看懂

实测 · 本机执行输出

event_name              total  total_latency  count_read  total_read  count_write  total_written
innodb/innodb_data_file  6730  768.31 ms      2050        31.98 MiB   3511         89.37 MiB
innodb/innodb_log_file   3184  431.71 ms      0           0 bytes     1985         103.53 MiB
innodb/innodb_dblwr_file 324   95.49 ms       2           16.00 MiB   158          50.58 MiB

innodb_log_file这一行真实count_read=0，只有写没有读——这跟redo log真实"只追加写入、几乎不会被读取"的特性完全对得上；innodb_dblwr_file这一行的66.58MiB(读16MiB+写50.58MiB)，真实和本文前面《Doublewrite Buffer》那一篇观察到的行为是同一套机制留下的真实痕迹。这些数字都是本机这台开发机长期运行下来真实累积的I/O统计，不是构造出来的样例。

结论：sys schema真实是performance_schema的一层"人话"包装

sys schema里的这类视图真实不是独立的数据来源——它们真实全部是对performance_schema底层原始表的查询封装，把纳秒级的TIMER_WAIT转换成真实带单位的毫秒/微秒显示，把字节数转换成真实带单位的KiB/MiB，把需要多表JOIN才能拼出来的关联关系真实预先写好。如果直接查performance_schema.file_summary_by_instance这张原始表，得到的是没有单位换算、需要自己按EVENT_NAME前缀分类聚合的原始数字——sys schema把这些真实重复的整理工作做成了现成的视图，是运维和排查问题时更常用的真实入口，而不是直接跟performance_schema的原始表打交道。

分步演示：sys schema真实是怎么把底层数字翻译成人话的

每一步都是本文上面用真实的sys schema视图跑出来的原始结果。

一行SQL，看懂真实的I/O分类画像

这一步新看到的文件类型

本文用到的工具

本机 MySQL 26.7.0（InnoDB），sys.io_global_by_wait_by_bytes / sys.statement_analysis
延续前面《Doublewrite Buffer》一篇的真实发现互相印证

下一篇 · MYSQL / INNODB 114

连接池与线程缓存