alter table会阻塞mysql从库sql线程，导致复制延迟飙升，因其单线程回放机制下ddl必须执行完毕才能处理后续事件，即使inplace操作在从库仍需重建、加锁和更新元数据。
DDL在主从复制中不是“执行完就完事”，而是会卡住整个SQL线程回放队列——哪怕只是一条ALTER TABLE，也可能让后续所有事务排队等它跑完。
为什么ALTER TABLE会让从库延迟飙升？
MySQL主从复制的SQL线程是单线程（除非显式开启并行复制），而DDL操作在从库上必须完整执行完，才能继续处理下一个事件。即使主库上ALTER TABLE用了ALGORITHM=INPLACE，从库仍需逐行重建、加锁、更新元数据，期间所有后续事务都被堵在relay log里。
- 大表
ADD COLUMN或MODIFY COLUMN时，从库回放时间可能远超主库（尤其IO弱、buffer pool小） - DDL语句本身不走行复制（RBR下仍是语句级传输），但若触发表重建，会伴随大量
UPDATE/INSERT行事件，进一步拉长relay log堆积 -
Seconds_Behind_Master在DDL执行中常“假为0”，直到DDL结束才跳变——监控容易漏掉正在发生的延迟
用pt-online-schema-change绕过SQL线程瓶颈
这个工具本质是“不直接ALTER原表”，而是建影子表、同步增量、原子切换，全程不阻塞主库写入，也避免从库SQL线程被DDL独占。
- 必须确保主从都启用
binlog_format=ROW，否则pt-osc的同步触发器日志无法被正确复制 - 从库不能有
read_only=ON以外的额外限制（比如super_read_only未关闭会导致pt-osc创建触发器失败） - 执行前先在从库上手动验证：能否对目标表建触发器、是否有足够空间建影子表、
innodb_log_file_size是否够撑住大批量INSERT - 命令示例：
pt-online-schema-change --alter "ADD COLUMN c1 INT" D=test,t=orders --execute --chunk-size=1000 --max-load="Threads_running=25"
如果必须用原生命令，怎么控制风险？
原生ALTER并非完全不能用，但得满足三个硬条件：表小、从库强、窗口准。
- 仅限
ALGORITHM=INPLACE, LOCK=NONE的变更（如ADD INDEX、DROP INDEX、ADD COLUMN非首列）；MODIFY COLUMN或CHANGE COLUMN大概率触发COPY，禁用 - 从库
innodb_buffer_pool_size至少为主库70%，且磁盘IO能力不低于主库（SSD+合理IOPS） - 避开业务高峰，同时检查
SHOW SLAVE STATUS\G中Seconds_Behind_Master和Relay_Log_Space是否稳定——后者突增说明relay log正在快速堆积 - 执行后立刻在从库查
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Query' AND INFO LIKE '%ALTER%'，确认没卡住
DDL执行后从库报错，别急着sql_slave_skip_counter
跳过错误看似快，实则埋雷：结构不一致→后续DML在从库执行失败→延迟持续累积→最终复制中断。
- 先看
Last_Error具体内容，常见如Table 'db.t1' doesn't exist，说明主库建表语句没传到从库（可能是主库binlog_format临时切回SBR，或从库重启丢失部分relay log） - 优先尝试
STOP SLAVE; SET GLOBAL relay_log_purge=OFF; START SLAVE;触发重拉缺失日志 - 若确认是DDL语法不兼容（如主库8.0用
JSON_TABLE，从库5.7不支持），必须升级从库版本，而不是跳过 - 真正要跳过的，仅限
DROP TABLE IF EXISTS在从库找不到表这类无害错误
最易被忽略的一点：DDL操作本身不产生显著延迟，但它的“副作用”——比如重建表引发的百万级行事件、触发器隐式更新、统计信息自动收集——才是压垮从库SQL线程的真凶。监控不能只盯Seconds_Behind_Master，得结合Relay_Log_Space增长速率、从库SHOW PROCESSLIST状态、以及slow_query_log里有没有长时间运行的ALTER或INSERT INTO ... SELECT。
