MySQL 8.0.14+ 才稳定支持 performance_schema 完整 stage 生命周期与资源映射，5.7 及以下因缺少关键 stage 事件聚合而基本不可行；需启用 performance_schema 及对应 consumers/instruments，再通过 events_stages_history_long 关联查询各阶段耗时（单位皮秒），但 TIMER_WAIT 仅为 wall-clock 时间，受调度影响大，非精确 CPU/IO 计数器。
MySQL 8.0+ 必须用 performance_schema + sys 视图，5.7 及以下基本不可行
MySQL 原生不提供类似 Oracle 的 SQL Monitor 或 PostgreSQL 的 EXPLAIN (ANALYZE, BUFFERS) 那种带实时资源消耗的执行计划。真正能拿到各阶段 CPU/IO 开销的，只有开启 performance_schema 并采集足够细粒度事件——而这个能力在 MySQL 5.7 中受限严重（比如缺少 statement/sql/select 下的 stage 事件聚合），实际可用性低；MySQL 8.0.14+ 才稳定支持完整 stage 生命周期与资源映射。
实操前先确认：
-
performance_schema必须启用：SELECT @@performance_schema;返回 1 - 关键消费者表要打开：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_stages_history_long', 'events_statements_history_long'); - 阶段事件必须启用：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'stage/%';
查单条 SQL 各 stage 的耗时与 IO 次数：用 sys.statement_analysis 快速定位，再钻取 performance_schema.events_stages_history_long
sys.statement_analysis 是个聚合视图，能快速看到某类语句平均耗时、扫描行数、临时表使用等，但它不暴露 stage 级别细节。真要看“从 opening tables → System lock → optimizing → statistics → … → Sending data”每个环节的 CPU 时间和物理 IO 次数，得手动关联原始事件表。
典型操作链：
- 先执行目标 SQL（确保没被 query cache 缓存，可加
SELECT SLEEP(0.01), ...或用SELECT /*+ NO_CACHE */ ...） - 立刻查：
SELECT THREAD_ID, EVENT_ID, SQL_TEXT FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%your_key_word%' ORDER BY TIMER_START DESC LIMIT 1; - 拿回
THREAD_ID和该语句的起始EVENT_ID，再查对应 stages：SELECT EVENT_NAME, TIMER_WAIT, WORK_COMPLETED, WORK_ESTIMATED FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID = [EVENT_ID] ORDER BY EVENT_ID;
注意：WORK_COMPLETED 对 IO 类 stage（如 stage/sql/Waiting for table flush）常为 0，但对 stage/sql/Sorting result 或 stage/sql/Creating sort index 可能反映内存排序量；TIMER_WAIT 是唯一可靠的时间指标，单位是皮秒（需除以 1000000000 转为毫秒）。
stage/sql/xxx 名称不等于真实系统行为，尤其 IO 相关 stage 很可能被合并或跳过
MySQL 的 stage 划分是逻辑标记点，不是内核 hook。比如 stage/sql/Opening tables 实际只记录打开表对象的开销，不含底层文件 open() 系统调用的磁盘寻道；stage/sql/Waiting for table level lock 不体现 InnoDB 行锁等待，它只针对 MyISAM 或显式 LOCK TABLES 场景。
真正反映物理 IO 的 stage 极少，常见且相对可信的只有：
-
stage/sql/Waiting for query cache lock（仅限启用 query cache 时，已弃用） -
stage/innodb/alter table: end（DDL 阶段刷脏页） -
stage/innodb/insert buffer merge（合并插入缓冲区时触发的随机读）
其余大部分 stage 的 TIMER_WAIT 主要是 CPU 时间，IO 开销需结合 performance_schema.file_summary_by_event_name 或 sys.io_global_by_file_by_latency 单独看文件读写统计，无法按 SQL 语句归属到具体 stage。
替代方案：用 pt-query-digest --explain + mysqld --log-slow-verbosity=full 捕获更贴近实际的资源痕迹
如果非要逼近真实 IO/CPU 分布，且无法升级到 MySQL 8.0.22+（支持 performance_schema.table_io_waits_summary_by_index_usage 细化索引级 IO），建议换路径：
- 开启慢日志全量采集：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0; SET GLOBAL log_slow_verbosity = 'full'; - 让目标 SQL 走一遍，然后用
pt-query-digest --explain h=localhost,u=root,p=xxx /var/lib/mysql/slow.log解析，它会把# Query_time、# Lock_time、# Rows_sent、# Rows_examined和EXPLAIN结果并列输出，间接反映 IO 压力（Rows_examined 高 ≈ 多次磁盘页读） - 配合
perf record -e syscalls:sys_enter_read,syscalls:sys_enter_pread64 -p $(pidof mysqld)抓系统调用，才能看到真实 read/pread64 调用次数与大小——但这已脱离 SQL 层，需运维介入
最易被忽略的一点：stage 事件默认不采集 memory 和 CPU cycle 级别数据，TIMER_WAIT 是 wall-clock 时间，受调度延迟、上下文切换影响极大；同一语句反复执行，各 stage 耗时波动可能达 30% 以上，不要当作精确性能计数器用。
