大表DDL让从库卡死几小时，因MySQL原生ALTER需持MDL锁且从库SQL线程串行执行，若表巨大、IO慢、buffer pool小，会停滞在altering table或Waiting for table metadata lock状态，Seconds_Behind_Master飙升至数万秒。

大表DDL为什么让从库卡死几小时

因为MySQL原生ALTER TABLE在主库执行时会持有元数据锁（MDL），binlog里这条语句仍以statement格式记录，哪怕binlog_format=ROW也无效。从库SQL线程必须串行执行完这个DDL才能继续——如果表有上亿行、IO慢、buffer pool小，它就真卡在altering table状态不动，Seconds_Behind_Master一路飙到几万秒，而SHOW PROCESSLIST里只看到一个Waiting for table metadata lock或copy to tmp table。

别直接在主库跑ALTER，改用gh-ost

gh-ost绕过MDL锁和单线程回放瓶颈，核心是不走MySQL原生DDL路径：

• 它在主库创建影子表，用轻量INSERT/UPDATE/DELETE同步原表变更，从库只回放这些DML，天然支持并行
• 最终只做一次RENAME，毫秒级原子切换，不阻塞主库写入
• 全程不依赖触发器，GTID模式下更稳定

必须满足的硬条件：

• 主库开启binlog_row_image=FULL
• 操作用户要有SELECT, INSERT, UPDATE, DELETE, CREATE, DROP权限
• 原表必须有唯一可排序索引（主键或NOT NULL UNIQUE）
• 命令里--alter参数只写变更部分，例如--alter="ADD COLUMN status TINYINT"，不带ALTER TABLE t1

如果必须用原生DDL，至少控制影响范围

线上实在没法切gh-ost，就得把风险收窄：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 避开业务高峰，选凌晨低TPS时段执行
• 提前在从库上预热：SELECT COUNT(*) FROM big_table触发buffer pool加载，避免DDL时大量磁盘读
• 临时调大从库资源：innodb_buffer_pool_size加到物理内存70%，innodb_log_file_size翻倍减少刷脏压力
• 执行前停掉从库所有长查询，防止SQL线程被Waiting for table flush卡住
• 监控Relay_Log_Space增长速度，若持续上涨说明relay log写不过来，需调大relay_log_space_limit

并行复制不是万能解药，但能缓解DDL后的堆积

DDL本身无法并行，但它后面跟着的几十万条DML可以——前提是配置正确：

• MySQL 5.7+：设slave_parallel_type = LOGICAL_CLOCK + slave_parallel_workers = 4~8，要求主库binlog_transaction_dependency_tracking = COMMIT_ORDER
• MySQL 8.0+：优先用WRITESET，需主库开binlog_transaction_dependency_tracking = WRITESET，对小事务加速明显
• 注意：如果DDL后紧跟着大批量UPDATE，且没走索引，从库可能因全表扫描再次卡住，得先确保相关字段有索引

真正容易被忽略的是DDL执行期间的“静默延迟”：Seconds_Behind_Master可能还显示0，但SQL线程早已停在DDL上不动了，必须看SHOW PROCESSLIST里SQL线程的真实状态。