不能在从库运行pt-online-schema-change，因为从库只读无法创建触发器和执行RENAME；强行执行会导致主从结构不一致、复制中断及查询错乱。
MySQL 5.7主从环境里改大表结构，必须在主库执行 pt-online-schema-change，且主从表结构要完全一致；否则 RENAME 操作会破坏从库数据一致性，甚至导致复制中断。
为什么不能在从库运行 pt-online-schema-change
这个工具依赖触发器和原子性 RENAME 操作，而从库是只读的，无法创建触发器，也无法执行写操作。即使绕过权限强行执行，也会出现以下问题：
- 从库上建的影子表、触发器不会同步到主库，主从结构立即不一致
- 工具执行到
RENAME阶段时，从库会报错ERROR 1044 (42000): Access denied for user或直接停止复制 - 主库后续 DML 仍写原表，但从库可能已把新表当原表，造成查询结果错乱
--alter 语句必须兼容主从当前版本与 SQL_MODE
MySQL 5.7 默认开启严格模式（STRICT_TRANS_TABLES），如果加字段时没给默认值又设了 NOT NULL，工具会在建影子表阶段就失败：
Level: Warning Code: 1364 Message: Field 'status' doesn't have a default value
正确写法必须显式指定 DEFAULT：
-
--alter "ADD COLUMN status TINYINT NOT NULL DEFAULT 0"✅ -
--alter "ADD COLUMN status TINYINT NOT NULL"❌（失败） - 若字段允许为空，可省略
DEFAULT，但建议仍写DEFAULT NULL明确语义
主从延迟高时要调低 --max-lag 和 --chunk-time
工具拷数据期间会持续检查从库延迟，一旦发现延迟超过 --max-lag（单位：秒），就会暂停拷贝，避免雪上加霜。生产环境中常见误配：
- 设
--max-lag=60却忽略从库常态延迟已达 40s，导致工具反复启停，总耗时翻倍 -
--chunk-time=1.0在 IO 压力大时单次拷贝超时，实际每批耗时可能达 3s，加重主从压力 - 推荐组合：
--max-lag=5 --chunk-time=0.3 --check-interval=2，适合大多数 5.7 主从集群
执行前必须验证 --dry-run 并确认从库无异常告警
--dry-run 不光看语法是否通过，更要检查三项真实状态：
- 输出中是否包含
Creatng new table...和Creating triggers...—— 确认触发器权限 OK - 日志末尾是否有
This operation will not make any changes—— 确保没误带--execute - 执行后立刻查从库：
SHOW SLAVE STATUS\G，确认Seconds_Behind_Master未跳变、SQL_Remaining_Delay为NULL
真正执行时，--execute 必须显式写出，缺省不生效；整个过程最易被忽略的是从库 relay log 是否有积压——积压未清空就 RENAME，会导致从库重放时找不到原表名而报错 Table doesn't exist。
