DDL卡住时SQL线程停在“altering table”不动，是因为MySQL 5.7从库SQL Thread单线程重放binlog，DDL触发全库级MDL锁升级，强制同库所有事务串行化执行，且Query_log_event无时间戳无法并行切分，即使启用database模式或多worker也无效。
DDL卡住时，SQL线程为什么停在“altering table”不动？
因为MySQL 5.7从库的SQL Thread是单线程重放binlog的，而DDL语句（如ALTER TABLE）会强制串行化整个库的操作。哪怕你只改user_order一张表，同库下所有表的DML事务都得排队等它结束——这不是慢，是彻底暂停。
典型现象：Seconds_Behind_Master持续上涨、SHOW PROCESSLIST里SQL Thread状态卡在altering table或Waiting for dependent transaction to commit，且Exec_Master_Log_Pos长时间不更新。
- DDL在binlog中是
Query_log_event格式，没有行级时间戳，无法被slave_parallel_type=database拆分到多个worker线程 - 即使开了8个
slave_parallel_workers，你也不会在SHOW FULL PROCESSLIST里看到它们参与DDL执行 - 根本原因不是IO或CPU瓶颈，而是MySQL内核把DDL当作“全库屏障”，自动将当前库所有pending事务路由到同一个worker
为什么slave_parallel_type=database对DDL完全无效？
这个参数只对DML生效：不同库的UPDATE/INSERT可以并发执行。但DDL自带隐式FLUSH TABLES WITH READ LOCK语义，会触发库级MDL锁升级，直接绕过并行调度逻辑。
你可以用SHOW VARIABLES LIKE 'slave_parallel_type'确认值是database，但这不代表DDL能并行——它只是告诉MySQL：“DML按库分发”，没说“DDL也照办”。
-
slave_parallel_type='logical_clock'（5.7.22+）能略微缓解，前提是主库开启binlog_transaction_dependency_tracking=WRITESET，但DDL本身仍无法切片 - DDL在relay log里就是一条长记录，没法像DML那样按chunk或时间戳切分重放
- 别指望
pt-online-schema-change自动解决从库问题——它只在主库生效，从库照样要重放原始DDL
如何快速判断是不是DDL导致从库延迟？
先看SHOW SLAVE STATUS\G里的关键字段：Slave_SQL_Running_State如果是altering table，基本就坐实了；再结合Relay_Log_Space是否持续增长、Seconds_Behind_Master是否稳定上涨不回落。
- 用
SHOW PROCESSLIST查SQL Thread的ID，然后SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE ID = [sql_thread_id]确认状态 - 不要只盯
INNODB_TRX——DDL阻塞的是MDL，不是InnoDB行锁，INNODB_TRX里可能查不到任何异常事务 - 真正该查的是
performance_schema.metadata_locks（5.7.3+），过滤OBJECT_SCHEMA和LOCK_STATUS = 'PENDING'，能直接看到谁在等哪张表的MDL
绕过从库DDL阻塞最可靠的实操方式
与其等SQL Thread慢慢啃完DDL，不如主动停掉它，在从库上手动执行——但必须确保主从数据一致，且DDL不涉及不可逆操作（比如DROP COLUMN）。
- 先执行
STOP SLAVE SQL_THREAD，让IO Thread继续拉binlog，SQL Thread暂停 - 用
mysqldump --no-data或mysqlcheck --check-upgrade校验目标表结构一致性 - 手动执行DDL前，加
SET SESSION lock_wait_timeout = 10，避免自己也被MDL卡住 - 成功后
START SLAVE SQL_THREAD，此时relay log里跳过这条DDL，后续DML正常追平
真正容易被忽略的是：DDL语句本身不会产生大量binlog日志，但它会让从库的SQL线程“失明”——在它执行期间，所有新到达的DML都被压在内存队列里，一旦DDL失败或中断，这些积压事务可能引发更复杂的回放冲突。
