MySQL 8.0.16+ 可通过 performance_schema.events_stages_current 查看 DDL 当前执行阶段及估算进度（WORK_COMPLETED/WORK_ESTIMATED），但仅对部分在线 DDL 有效；State 为 “altering table” 不代表实际进展，需结合 data_lock_waits、INNODB STATUS 和 I/O 状态综合判断。
MySQL 8.0+ 中如何查看正在运行的 DDL 进度
MySQL 原生不提供类似 SHOW PROCESSLIST 那样直接显示 DDL 进度百分比或预估剩余时间的功能。但自 MySQL 8.0.16 起，可通过 performance_schema 中的表（尤其是 data_lock_waits 和 stage_events_*）间接判断 DDL 是否卡在某个阶段。最实用的是查 performance_schema.events_stages_current，它能反映当前线程所处的执行阶段。
关键前提是：DDL 必须是支持在线 DDL 的操作（如 ADD COLUMN、CREATE INDEX），且启用了 innodb_status_output 或已开启相关 performance_schema 消费者。
- 确保启用 stage 相关消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_stages%'; - 查询当前 DDL 线程的阶段：
SELECT THREAD_ID, EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM performance_schema.events_stages_current WHERE EVENT_NAME LIKE 'stage/innodb/%' AND WORK_ESTIMATED > 0; -
WORK_COMPLETED和WORK_ESTIMATED是估算值，仅对部分 DDL（如ALTER TABLE ... ALGORITHM=INPLACE中的二级索引构建）有效，不是所有 DDL 都填充这两个字段
为什么 information_schema.PROCESSLIST 显示 State 为 altering table 却不动
这个状态只是表示线程进入了 ALTER 流程，并不反映内部真实进度。常见卡点包括：等待元数据锁（MDL）、等待 InnoDB 行锁、I/O 瓶颈、或正在做全表拷贝（ALGORITHM=COPY）。此时 State 不会变，但实际已停滞。
- 先查是否被阻塞：
SELECT * FROM performance_schema.data_lock_waits;—— 若有记录，说明当前 DDL 线程正等待其他事务释放锁 - 再看事务是否活跃：
SELECT THREAD_ID, PROCESSLIST_INFO FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_INFO LIKE 'ALTER%'; - 注意：如果
PROCESSLIST_INFO为空，说明语句已被解析并进入执行阶段，但performance_schema可能尚未捕获到 stage 事件（需确认 consumers 是否开启）
SHOW ENGINE INNODB STATUS 能否看出 DDL 进度
不能直接看到“还剩多久”，但可发现关键线索。执行后重点关注 TRANSACTIONS 和 FILE I/O 部分：
- 在
TRANSACTIONS列表中查找ALTER TABLE对应的事务 ID，看其lock struct(s)数量是否持续增长（说明正在逐页加锁扫描） - 在
FILE I/O部分观察pending normal aio reads/writes：若长期非零且数值较大，可能正密集读写临时文件（如排序建索引），此时进度缓慢但仍在推进 - 注意：该命令输出不实时刷新，两次执行间隔建议 ≥5 秒；且只反映 InnoDB 层，不包含 MyISAM 或复制延迟等外部因素
第三方工具或替代方案的实际效果
pt-online-schema-change（Percona Toolkit）和 gh-ost 是更可靠的在线 DDL 替代方案，它们自身会暴露进度（如 --print-progress 输出百分比），但本质是绕开原生 DDL，用影子表 + 触发器同步实现。
- pt-osc 默认每 30 秒打印一次进度，格式类似：
Copied rows 12450000/24900000 50% - gh-ost 支持 HTTP 接口（
http://localhost:8067/status）返回 JSON 进度，含elapsed、copied、total字段 - 但二者都有代价：额外资源占用、触发器开销、binlog 增大；且无法用于某些场景（如修改主键、外键约束变更）
真正想监控原生命令的进度，目前没有银弹——要么依赖 performance_schema 的有限估算字段，要么结合锁等待、I/O、事务状态做交叉推断。最容易被忽略的是：很多所谓“卡住”的 DDL，其实只是没在你预期的路径上推进，比如它正在重建聚簇索引而非你认为的二级索引。
