从库执行DDL会导致全局MDL等待，因SQL线程需排他元数据锁，阻塞所有对该表的读写及DDL操作，必须定位并终止持有锁的源头事务，而非直接KILL ALTER线程。

不能靠“从库先改再切主”来规避锁表风险。这种操作在绝大多数情况下会引发主从 GTID 错乱、binlog 位置跳变、SQL 线程 crash，甚至导致从库重放失败后永久中断同步。

为什么从库执行 ALTER TABLE 仍会卡住主库？

MySQL 的 DDL 复制不是“只传结果”，而是“传语句 + 重放”。即使你在从库上手动执行 ALTER TABLE，只要没停 SQL_THREAD，该语句就会被写入从库的 binlog（如果 log_slave_updates=ON），再传回主库重放——形成闭环污染。

• 更常见的情况是：主库执行了 ALTER TABLE ... ALGORITHM=INPLACE，但 binlog 记录为 COPY 模式（比如改 VARCHAR 长度、加 NOT NULL 且含 NULL 值），从库 SQL 线程只能重建整表，全程加 MDL 锁，阻塞所有查询
• binlog_row_image=MINIMAL 开启时，某些 DDL 的 row event 缺失字段，从库报错 Last_SQL_Errno: 1785
• GTID 模式下，若中途执行 SET GLOBAL sql_log_bin = 0，gtid_executed 在主从间无法对齐，后续 START SLAVE 直接失败

pt-online-schema-change 必须显式控制从库行为

pt-online-schema-change 默认只连主库，对从库完全无感。漏掉关键参数，会导致“主库结构已更新，从库还在用旧表”的静默不一致。

• 必须加 --recursion-method=none：禁用自动探测拓扑，避免误连二级从库
• 必须指定监控目标从库：--check-slave-lag=h=10.0.1.2,u=repl,p=xxx,P=3306，延迟超阈值（如 30 秒）自动暂停拷贝
• 必须提供从库账号：--slave-user=repl --slave-password=xxx，否则跳过 SELECT COUNT(*) 校验，你根本不知道主从是否真一致

示例命令：pt-online-schema-change D=test,t=orders --alter "ADD COLUMN flag TINYINT DEFAULT 0" --recursion-method=none --check-slave-lag=h=10.0.1.2,u=repl,p=xxx --slave-user=repl --slave-password=xxx --execute

MySQL8 CRM Schema Design Expert

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

下载

ALGORITHM=INPLACE + LOCK=NONE 不等于“零影响”

即使 MySQL 8.0+ 支持末尾加字段这类真正 INPLACE 操作，仍需满足三重前提，缺一不可：

• 主从版本完全一致（比如都是 8.0.33），且都开启 binlog_format=ROW
• DDL 执行前，确认 Seconds_Behind_Master 归零，并在执行中持续盯紧该值；延迟回升说明从库 SQL 线程开始积压
• 执行后必须校验 GTID：主库执行 SELECT @@global.gtid_executed，从库执行同一条语句，结果必须完全相等，不能只是“包含”

一旦涉及 MODIFY COLUMN、索引重建、列顺序调整或非末尾加字段，InnoDB 仍可能退化为 COPY 模式，从库照样卡死。

真正危险的不是“能不能改”，而是改的过程中没人盯着 SHOW PROCESSLIST 里有没有 Waiting for table metadata lock，以及从库 SHOW SLAVE STATUS 里 Seconds_Behind_Master 是否突然归零又飙升——这两个信号往往意味着复制已进入不可逆的故障链。