MySQL 5.7中DDL始终单线程串行执行，因DDL以STATEMENT格式记录、不支持LOGICAL_CLOCK切片，即使启用并行复制（slave_parallel_type='LOGICAL_CLOCK'）也仅能缓解依赖事务，无法真正并行；根本解决需STOP SLAVE后手动执行或使用gh-ost等工具绕过。
DDL在从库是单线程串行重放的
MySQL 5.7默认的slave_parallel_type=database只对DML生效，DDL语句没有“库隔离”豁免权。一旦主库执行ALTER TABLE，binlog里只记一条Query_log_event，从库SQL Thread必须全程独占执行——期间所有后续事务（哪怕操作的是user_config表）都得排队等待。
常见现象包括：SHOW PROCESSLIST里SQL Thread状态卡在altering table或Waiting for dependent transaction to commit；Exec_Master_Log_Pos长时间不动；Seconds_Behind_Master持续上涨且不回落。
这不是“慢”，是停摆：主库可能10秒完成，但从库SQL线程被锁死，后面几百个事务全堵着。
DDL自带隐式FLUSH TABLES WITH READ LOCK语义
即使你只改order_detail一张表，DDL也会触发整个库级别的MDL锁升级。MySQL内核会强制把当前库下所有pending事务路由到同一个worker，实际退化为单线程——slave_parallel_workers=4完全无效。
关键点在于：binlog_format=ROW对DDL没用。DDL始终以statement形式记录，无法按行级时间戳切片，logical_clock机制也无能为力。
验证方式：SHOW VARIABLES LIKE '%slave_parallel_type%'返回database ≠ DDL能并行；SHOW FULL PROCESSLIST里永远只看到1个活跃SQL线程处理DDL。
绕过延迟的实操路径只有两个
真正有效的方案不是调参数，而是改变执行逻辑：
- 切到
slave_parallel_type='logical_clock'（MySQL 5.7.22+），配合binlog_transaction_dependency_tracking=WRITESET，能让DDL前后的事务带上依赖时间戳——但只是缓解，不能根治 - 更可靠的做法是“主动绕过”：在从库上先
STOP SLAVE，手动执行DDL（需提前校验主从数据一致性），再START SLAVE。注意：SET sql_log_bin=0后执行的DDL不会写入binlog，主库不会同步该变更，务必确认业务是否允许这种主从结构短暂不一致
用gh-ost也是一种选择，但它默认连接主库，在主库创建影子表并监听binlog增量——从库只回放轻量DML和最终一次RENAME，不碰原DDL。但前提是主库已开binlog_row_image=FULL，且有唯一可排序索引。
最容易被忽略的细节
很多人以为“开了并行复制就万事大吉”，却没意识到DDL根本不在并行调度范围内；也有人直接在从库SET sql_log_bin=0执行DDL，忘了检查GTID一致性或未验证表结构是否真的一致——这类操作一旦出错，主从数据分裂很难回滚。
DDL延迟的本质不是IO或CPU瓶颈，是MySQL复制模型里对元数据变更的保守设计。它宁可卡住，也不愿冒险并发。所以判断是否为DDL导致延迟，第一反应不该是加资源，而是看Slave_SQL_Running_State和Exec_Master_Log_Pos是否冻结。
