查不到events_stages_current数据，是因为其消费者和stage仪器默认关闭，需手动启用setup_consumers和setup_instruments中对应项，并新建连接才生效。
查不到events_stages_current数据？先确认消费者和采集器是否真开了
很多人执行SELECT * FROM performance_schema.events_stages_current;返回空，就以为没阶段数据——其实只是events_stages_current这个消费者默认关闭了。它不像events_statements_current那样“开箱即用”。
必须手动启用两个关键项：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_stages_current', 'events_stages_history_long');UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'stage/innodb/%' OR NAME LIKE 'stage/sql/%';
改完后**必须新开连接**（老连接不会自动加载新 stage 事件）；再查threads表确认当前会话的THREAD_ID存在，否则 stage 数据不会归属到你。
WORK_COMPLETED和WORK_ESTIMATED不是百分比，别直接除
这两个字段单位是抽象“工作单元”，不是行数、字节数或时间。比如stage/innodb/alter table (read PK)里的WORK_ESTIMATED初始值是预估的 B+ 树页数，后续会动态修正；WORK_COMPLETED是已处理页数，但不等于“已完成 70%”。
常见误用：
- 用
WORK_COMPLETED / WORK_ESTIMATED算进度 → 结果可能突变甚至 >1.0 - 对非 InnoDB DDL（如
CREATE TABLE AS SELECT）依赖该字段 → 它们压根不填WORK_ESTIMATED - 在
events_stages_history_long里查历史阶段 → 这张表只存最近 10000 条，且需HISTORY为 YES 的线程才写入
真正可用的判断方式：看EVENT_NAME是否在持续变化（如从stage/innodb/alter table (read PK)推进到stage/innodb/alter table (merge sort)），说明 DDL 确实在动。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
想关联 SQL 文本？别只查events_stages_current
events_stages_current本身不存 SQL，它只记录线程当前所处的执行阶段。要还原完整上下文，必须连查三张表：
- 从
events_stages_current拿到THREAD_ID和EVENT_NAME - 用
THREAD_ID去events_statements_current查SQL_TEXT（注意：如果语句已执行完、线程处于 sleep，这里为空） - 若
events_statements_current.SQL_TEXT为空，再用THREAD_ID查threads表的PROCESSLIST_ID，然后SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE ID = ?补全原始语句
漏掉最后一步，就会看到 stage 在跑，却不知道对应哪条ALTER TABLE——尤其在线上多租户或 ORM 自动生成语句的环境里，这步缺失等于白查。
DDL 卡住时，State = 'altering table'是假象
INFORMATION_SCHEMA.PROCESSLIST显示State为altering table，不代表它正在干活。MySQL 8.0 的这个状态只表示线程进入了 ALTER 流程，实际可能卡在：
- 等元数据锁：
SELECT * FROM performance_schema.data_lock_waits;有记录，且BLOCKING_TRX_ID指向一个长时间未提交的事务 - 等行锁：
data_locks里看到大量RECORD锁，但data_lock_waits为空 → 持锁者没被等，只是它自己在等别的锁 - I/O 堵塞：
SHOW ENGINE INNODB STATUS里FILE I/O部分有大量 pending read/write，或系统层iostat -x 1显示 %util 接近 100%
这时候光盯events_stages_current没用——阶段停在stage/innodb/alter table (flush)不动，真正瓶颈可能在磁盘，而不是 SQL 执行逻辑本身。
