pt-osc执行前必须满足三项硬性条件：表有主键或唯一索引、原表无任何触发器、操作用户具备trigger/replication slave/process权限；不满足则直接报错退出，非警告。
pt-osc 执行前必须检查的三项硬性条件
不满足这三条，pt-online-schema-change 会直接报错退出，不是警告，是拒绝执行。
- 表必须有主键或唯一索引（否则无法分块复制和触发器精准定位行）
- 原表不能已有任何触发器（
pt-osc要自己建 INSERT/UPDATE/DELETE 三类触发器，冲突即失败） - 操作用户需具备
trigger、replication slave、process权限（缺trigger会提示 “You do not have the TRIGGER privilege”）
常见误判是以为“有索引就行”，但普通二级索引不满足要求；也有人忽略 replication slave 权限——即使单机部署，该权限也用于读取 binlog position 做延迟判断。
为什么 --dry-run 不等于安全，而 --execute 才暴露真问题
--dry-run 只校验语法、权限、表结构兼容性，它不会创建触发器、不连从库、不测复制延迟。真正风险点在 --execute 阶段才浮现。
- 触发器创建失败：比如表名含特殊字符或数据库名用了反引号，
--dry-run不报，--execute却卡在 trigger 步骤 - 从库延迟超限：若启用了
--check-replica-lag，但某从库因慢查询积压了 120 秒，pt-osc会暂停拷贝并持续轮询，看起来像“卡住” - 主键字段被修改：如
--alter "MODIFY id BIGINT UNSIGNED"，虽语法合法，但触发器中OLD.id NEW.id比较可能因隐式类型转换失效，导致 UPDATE 同步丢失
建议始终加 --print 参数，看它实际生成的 CREATE TRIGGER 和 REPLACE INTO 语句是否符合预期。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
ALGORITHM=INSTANT 的字段变更，别用 pt-osc
MySQL 8.0.12+ 对 ADD COLUMN、DROP COLUMN、CHANGE COLUMN（仅限长度扩展）等操作支持 ALGORITHM=INSTANT，这类变更毫秒级完成，且完全无锁。
- 用
pt-osc做ADD COLUMN是杀鸡用牛刀：多出触发器开销、数据拷贝压力、临时表空间占用 - 更危险的是，
pt-osc的REPLACE INTO在遇到NOT NULL新列且无默认值时，会因缺失值写入失败，而原生INSTANT会自动补DEFAULT或NULL - 验证方式：
ALTER TABLE t ADD COLUMN c INT DEFAULT 0, ALGORITHM=INSTANT;成功即表示可用，此时应直接走原生 DDL
混淆点在于：pt-osc 不识别 INSTANT 能力，它一律按老流程走影子表+触发器，白白放大风险面。
切换时刻的原子性依赖 RENAME TABLE，但你得盯住外键
pt-osc 最后一步是 RENAME TABLE t TO _t_old, _t_new TO t，这是 MySQL 原子操作，业务几乎无感。但外键约束不会自动迁移。
- 若其他表的外键指向
t(id)，切换后仍指向旧表_t_old，新插入会报Cannot add or update a child row: a foreign key constraint fails - 必须提前用
--alter-foreign-keys-method=drop_swap或rebuild_constraints，否则工具默认跳过外键处理 - 更隐蔽的问题：外键引用的列名若在新表中被重命名（如
user_id → uid），rebuild_constraints会失败，必须人工干预
这不是理论风险——线上真实案例中，因漏配 --alter-foreign-keys-method，切换后 5 分钟内 3 张子表写入全挂。
