gh-ost必须用trigger仅用于启动时“窗口期”变更捕获，全量拷贝后立即删除；pt-osc默认全程依赖trigger，--no-triggers模式则通过分片轮询补数据，易因并发插入、无事务包裹等导致遗漏。
gh-ost 为什么一定要用 trigger，而 pt-osc 可以不用
gh-ost 的核心设计是“无锁、可暂停、基于 binlog 的增量同步”，它不依赖 MySQL 原生的触发器来捕获 DML 变更，而是通过解析 binlog 拿到 INSERT/UPDATE/DELETE 事件，再重放进影子表。但注意：它**在启动阶段仍需创建一个临时 trigger**——仅用于捕获从开始监听 binlog 到第一行数据拷贝完成之间的“窗口期”变更（即所谓“catch-up phase”）。这个 trigger 是轻量、短命、只作用于原表的 INSERT/UPDATE/DELETE，且会在全量拷贝结束后立即删除。
pt-online-schema-change（简称 pt-osc）则相反：它默认全程依赖 trigger（BEFORE INSERT/UPDATE/DELETE），把所有原表变更实时同步到影子表。它的 “triggerless” 模式（需显式加 --no-triggers）本质是放弃实时同步能力，改为靠定期轮询 SELECT ... FOR UPDATE + REPLACE INTO 来追赶，只适用于低频写入、允许短暂数据不一致的场景。
常见错误现象：gh-ost 启动时报 ERROR 1419 (HY000): You do not have the SUPER privilege，就是因为用户没开 log_bin_trust_function_creators 或没给 TRIGGER 权限；而 pt-osc --no-triggers 在高并发写入下容易卡住或丢变更，日志里反复出现 Waiting for the original table to be idle。
triggerless 模式下 pt-osc 怎么补数据，为什么容易漏
pt-osc --no-triggers 不建 trigger，改用“查旧表 → 写新表 → 标记已处理”三步循环，靠 WHERE 条件分片扫描原表主键范围，每次处理一批（默认 --chunk-size=1000）。它用 SELECT ... FOR UPDATE 锁住当前 chunk，再 REPLACE INTO 影子表，最后删掉这批记录的标记（实际是更新 _pt_osc_db_tbl_del 辅助表）。
问题就出在这个“查-锁-写”链路上：
- 写入发生在查询之后，中间有时间差，新插入的行可能被跳过
-
FOR UPDATE只锁住 select 出来的行，不阻塞新插入（gap lock 不生效），导致并发 insert 落入空隙、逃逸 - 如果原表有
ON DUPLICATE KEY UPDATE或REPLACE语义，REPLACE INTO无法等价模拟 - 没有事务包裹整个 chunk 操作，失败后恢复逻辑脆弱，容易重复或遗漏
所以 --no-triggers 仅适合只读迁移、归档表、或明确接受数秒级不一致的离线任务。
gh-ost 的 trigger 生命周期有多短，哪些权限必须给
gh-ost 创建的 trigger 只存在于“全量拷贝开始前”到“全量拷贝完成、开始 binlog 追赶”之间，通常几秒到几分钟，取决于表大小和 --chunk-size。它只建三个 trigger：gho_after_insert、gho_after_update、gho_after_delete，全部 AFTER 类型，且只对原表生效。
必须授予的权限：
-
TRIGGER（创建/删除 trigger） -
SUPER或REPLICATION CLIENT（查 master status、show binary logs） -
REPLICATION SLAVE（连接 binlog dump） -
SELECT、INSERT、UPDATE、DELETE、DROP、CREATE（操作影子表）
注意：gh-ost 不需要 ALTER 权限，也不修改原表结构；但若用 --allow-on-master 直接在主库跑，务必确认 binlog_format = ROW，否则解析失败。
线上选型时，什么情况该坚持用 pt-osc trigger，什么该切 gh-ost
pt-osc 的 trigger 模式稳定、兼容老版本 MySQL（5.1+）、支持复杂外键和自增逻辑，但 trigger 本身会拖慢原表写入（尤其高 QPS 下），且一旦 trigger 报错（比如影子表字段类型不匹配），整个 DDL 就卡死，必须人工干预。
gh-ost 触发器生命周期短、写入无感、支持暂停/回退/动态调速，但要求 MySQL ≥ 5.6、binlog_format = ROW、且不支持外键约束自动迁移（需手动处理）。
实操建议：
- MySQL 5.7+、业务能接受短时 binlog 增量延迟 → 优先
gh-ost - 有外键、或使用 Percona Server 5.6 以下 → 只能用
pt-osctrigger 模式 - 想绕开 trigger 却又不敢用
--no-triggers→ 不如别绕，直接换gh-ost - 测试环境验证时，务必用
--test-on-replica+--execute组合，避免主库误操作
真正难的不是选工具，是搞清你那张表有没有 GENERATED COLUMN、是不是 TokuDB 引擎、binlog 是否被 replicate-ignore-db 过滤了——这些细节一漏，两个工具都会静默失败。
