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 <p>注意：<code>INNODB_TRX</code> 不记录 DDL 自身（它不进事务表），但会暴露那个“占着行不让走”的事务。</p><h3> <code>SHOW ENGINE INNODB STATUS</code> 里的隐藏线索</h3> 这个命令不会直接告诉你“还剩多久”，但能暴露关键瓶颈： <p>在输出的 <code>TRANSACTIONS</code> 部分看是否有长时间未提交事务；</p><p>在 <code>LATEST FOREIGN KEY ERROR</code> 或 <code>LATEST DEADLOCK</code> 部分确认是否因约束冲突反复重试；</p><p>在 <code>SEMAPHORES</code> 部分如果 <code>os wait array slots</code> 持续满，说明 I/O 或 CPU 成瓶颈；</p><p>最关键的线索在 <code>INSERT BUFFER AND ADAPTIVE HASH INDEX</code> 下方——若看到 <code>merged operations</code> 值极低，或 <code>pending reads/writes</code> 长时间不降，大概率是磁盘吞吐拖慢了 DDL。</p><p>别指望它刷新快：该命令输出是快照，两次执行间隔至少 5 秒才有意义对比。</p><p>真正麻烦的是那些既不填 <code>WORK_COMPLETED</code>、又没锁等待、<code>INNODB STATUS</code> 也看不出异常的 DDL——它可能正默默做全表拷贝，或者卡在 buffer pool 刷脏页环节。这种时候，<code>iotop -p $(pidof mysqld)</code> 和 <code>pt-ioprofile</code> 才是最后的真相。</p>
