会断同步，但非必然；问题源于执行时机与binlog格式：STATEMENT下易主从不一致，ROW下大表DDL拖慢从库重放致SQL线程停止。
主从同步中直接执行 ALTER TABLE 会断同步吗？
会，但不是必然。MySQL 主从同步本身不阻塞 DDL，但问题出在「执行时机」和「binlog 格式」上：STATEMENT 格式下某些 DDL（比如带子查询的 ALTER TABLE ... SELECT）可能主从不一致；ROW 格式虽安全，但大表 ALTER TABLE 会生成海量 binlog，拖慢从库重放，甚至触发 slave_sql_running=No。
常见错误现象：Seconds_Behind_Master 突然飙升、从库报 Deadlock found when trying to get lock、或 Could not execute Write_rows event（主从表结构已不一致时）。
- 务必确认
binlog_format=ROW，5.7+默认如此，但老实例常是STATEMENT - 避免在业务高峰期执行，DDL 期间主库写入会被锁（
ALGORITHM=INPLACE也非完全无锁） - 执行前用
SHOW SLAVE STATUS\G检查Seconds_Behind_Master是否为 0，否则先追平
pt-online-schema-change 为什么比原生命令更稳？
它不直接改原表，而是新建影子表、用触发器同步增量、再原子切换，规避了锁表和从库延迟放大问题。但前提是：主从延迟不能太大（否则触发器堆积导致主库压力高），且必须关闭从库的 sql_log_bin（仅限临时操作）。
使用场景：500 万行以上、无法停写、要求主从强一致的线上表。
- 必须加
--check-interval=1防止检测间隔过长错过延迟突增 - 慎用
--chunk-index：若指定的索引非唯一或有 NULL 值，会导致数据丢失 - 执行后立刻检查从库是否完成切换：
SELECT COUNT(*) FROM tbl_new和原表对比，别只信pt-osc的 success 提示
MySQL 8.0+ 的 ALTER TABLE ... ALGORITHM=INSTANT 能无感执行吗？
能，但限制极多：只支持添加/删除列、修改列默认值、重命名列，且不能是主键、不能有全文索引、不能是虚拟列。一旦不满足，MySQL 会自动降级为 INPLACE 或 COPY，而你根本不会收到警告。
性能影响：真正 INSTANT 时，毫秒级完成，binlog 只记元数据变更，从库几乎无感知。
- 执行前先查
information_schema.INNODB_TABLES确认表引擎是InnoDB - 用
ALTER TABLE t ADD COLUMN c1 INT DEFAULT 0, ALGORITHM=INSTANT;测试是否报错，别直接套用到生产 - 注意：8.0.12+ 才支持
INSTANT添加列；8.0.23+ 才支持删除列；版本太低会静默回退
从库执行 DDL 会跳过同步吗？
不会跳过，但可能被跳过——取决于 replicate_ignore_db、replicate_do_table 等过滤规则，以及是否开启 skip_slave_start 导致从库重启后没拉起 SQL 线程。
更危险的是手动在从库执行 DDL：一旦结构和主库不一致，后续主库的 DML 就可能在从库报错中断同步，比如主库插入一行，从库因字段数不匹配直接 SQL Thread stopped。
- 绝对禁止在从库执行任何 DDL，除非你明确要拆分读写结构（且已做好应用层兼容）
- 若误操作已发生，别硬启同步，先用
mysqldump --no-data对比主从表结构差异 - 修复时优先用
pt-online-schema-change在主库补操作，而不是反向改从库
最易被忽略的一点：DDL 执行过程中如果主库 crash，而 binlog 还没刷盘，从库可能卡在半截状态，此时 START SLAVE 不会自动恢复，得人工校验 GTID 或 binlog position 后 CHANGE MASTER TO 重设。
