如何在MySQL中查询正在执行的DDL进度及剩余时间？-mysql教程-PHP中文网

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中查询正在执行的ddl进度及剩余时间？

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 不会变，但实际已停滞。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

先查是否被阻塞：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，其实只是没在你预期的路径上推进，比如它正在重建聚簇索引而非你认为的二级索引。