不建议在从库先行执行大表字段修改，因ROW/MIXED模式下从库DDL会写入binlog并回传主库，导致主库卡顿；STOP SLAVE SQL_THREAD则主动破坏主从一致性，易引发GTID gap或Write_rows执行失败；真正安全方案是优先使用ALGORITHM=INPLACE,LOCK=NONE或pt-online-schema-change工具。
不建议在从库先行执行大表字段修改，这种做法在绝大多数生产场景下是危险且无效的。
从库执行 ALTER TABLE 仍会同步回主库
MySQL 默认开启 binlog_format=ROW（或 MIXED）时，从库上执行的 DDL 语句会被记录进自己的 binlog，并通过复制机制传回主库重放。这意味着：你看似“绕开主库”，实际只是把锁表、拷贝、重建索引的动作延迟到了主库追日志那一刻——主库照样卡住，业务照样中断。
唯一能阻止同步的方式是显式执行 STOP SLAVE SQL_THREAD，但这等于主动撕裂主从关系，后续恢复极易触发 GTID gap 或 Could not execute Write_rows event 错误。
从库先行改结构 ≠ 主从切换前的安全垫
主从切换依赖数据和位点严格一致。而大表 DDL 在从库执行后：
- 若未等
Seconds_Behind_Master归零就切主，新主库 binlog 位置缺失，旧主库重连后直接报错； - 若 DDL 涉及
MODIFY COLUMN或索引重建，从库重放时可能因数据校验失败（如类型转换溢出、NOT NULL 约束冲突）直接 crash； - 即使成功，从库 DDL 耗时通常比主库更长（硬件弱、负载高），反而拉长风险窗口。
真正可控的方案只有两个方向
一是确认操作可走 ALGORITHM=INPLACE, LOCK=NONE：比如 MySQL 8.0+ 对末尾加字段、改注释、调宽 VARCHAR，且表无全文索引、无外键、无生成列——这时主库直接执行也几乎无感。
二是放弃原生 DDL，用 pt-online-schema-change：
- 它不依赖主从状态，主库单点操作即可；
- 通过触发器捕获增量，分 chunk 拷贝，全程原表可读写；
- 必须确保原表有主键或唯一非空索引，否则无法分片；
- 命令里一定要带
--max-lag=5和--critical-load，防止拖垮从库或引发雪崩。
所谓“从库先行”，本质是对 MySQL 复制机制的误读。真正要盯死的，从来不是在哪台机器上敲命令，而是这个 DDL 到底走不走拷贝、锁不锁表、会不会让主库在某次心跳后突然失联。
