SHOW PROCESSLIST无法反映真实DDL进度，仅显示altering table等模糊状态；MySQL原生不提供百分比或剩余时间，8.0.16+需结合performance_schema.events_statements_current（查完整语句与EXECUTING状态）、events_stages_current（限INPLACE DDL的WORK_COMPLETED/WORK_ESTIMATED估算）、data_lock_waits及metadata_locks综合判断卡点。
SHOW PROCESSLIST 看不到真实 DDL 进度，它只显示 State 为 altering table 或 Waiting for table metadata lock，但这不代表正在干活——可能卡在锁、I/O 或内部阶段里。MySQL 原生不提供“还剩 X%”或“预计 Y 分钟”的接口，但 8.0.16+ 可通过 performance_schema 拆解出部分可读线索。
查 events_statements_current 拿到完整 DDL 语句
INFORMATION_SCHEMA.PROCESSLIST 的 INFO 列默认截断（最多 1024 字节），长 ALTER TABLE 会被砍掉，导致你看到的不是真语句。而 performance_schema.events_statements_current 是唯一能拿到完整 SQL 和真实执行状态的来源。
确保已启用 performance_schema（SELECT @@performance_schema 返回 1）；若为 0，需在配置文件加 performance_schema = ON 并重启 mysqld。
执行以下查询确认当前真正在跑的 DDL：
SELECT THREAD_ID, SQL_TEXT, STATE FROM performance_schema.events_statements_current WHERE STATE = 'EXECUTING' AND SQL_TEXT REGEXP '^(ALTER|CREATE|DROP|RENAME|TRUNCATE)';
注意：STATE = 'EXECUTING' 才代表真正进入执行阶段；QUEUED 或 CALCULATING 都不算。
用 events_stages_current 看当前执行阶段（仅限部分 DDL）
不是所有 DDL 都支持进度估算，只有启用了 ALGORITHM=INPLACE 且属于 InnoDB 内部支持的类型（如加索引、加列）才可能填 WORK_COMPLETED 和 WORK_ESTIMATED。
先打开 stage 相关消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_stages%';
再查当前线程所处阶段：
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;
常见有效阶段包括：stage/innodb/alter table (read PK and internal sort)、stage/innodb/alter table (write clustered index)；但 ALGORITHM=COPY 或涉及外键重建时，这两个字段常为 NULL。
WORK_COMPLETED / WORK_ESTIMATED 是粗略估算值，不是百分比，且不保证实时更新——可能卡住几秒不变化。
查 data_lock_waits 和 metadata_locks 判断是否被堵死
DDL 卡住最常见原因是锁：要么等元数据锁（SCH_M），要么等行级锁（比如被长事务阻塞二级索引重建）。
查谁在等锁：
SELECT * FROM performance_schema.data_lock_waits;
查谁持有 DDL 必需的锁：
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_DURATION, LOCK_STATUS, SOURCE FROM performance_schema.metadata_locks WHERE LOCK_TYPE = 'EXCLUSIVE' AND LOCK_STATUS = 'GRANTED' AND OBJECT_TYPE = 'TABLE';
再结合 INNODB_TRX 找出拦路的事务：
SELECT TRX_ID, TRX_STARTED, TRX_STATE, TRX_QUERY FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'RUNNING' AND TRX_STARTED < NOW() - INTERVAL 60 SECOND;
注意：INNODB_TRX 不记录 DDL 自身（它不进事务表），但会暴露那个“占着行不让走”的事务。
SHOW ENGINE INNODB STATUS 里的隐藏线索
这个命令不会直接告诉你“还剩多久”，但能暴露关键瓶颈：
在输出的 TRANSACTIONS 部分看是否有长时间未提交事务；
在 LATEST FOREIGN KEY ERROR 或 LATEST DEADLOCK 部分确认是否因约束冲突反复重试；
在 SEMAPHORES 部分如果 os wait array slots 持续满，说明 I/O 或 CPU 成瓶颈；
最关键的线索在 INSERT BUFFER AND ADAPTIVE HASH INDEX 下方——若看到 merged operations 值极低，或 pending reads/writes 长时间不降，大概率是磁盘吞吐拖慢了 DDL。
别指望它刷新快：该命令输出是快照，两次执行间隔至少 5 秒才有意义对比。
真正麻烦的是那些既不填 WORK_COMPLETED、又没锁等待、INNODB STATUS 也看不出异常的 DDL——它可能正默默做全表拷贝，或者卡在 buffer pool 刷脏页环节。这种时候，iotop -p $(pidof mysqld) 和 pt-ioprofile 才是最后的真相。
