gh-ost 默认禁用 trigger，因其不监听、不兼容、也不保证 trigger 行为一致性；它依赖 binlog 解析与模拟写入，而 trigger 在 MySQL server 层原始 DML 时触发，二者路径完全隔离。
gh-ost 为什么默认禁用 trigger
因为 gh-ost 在执行 online schema change 时，**不监听、不兼容、也不保证 trigger 的行为一致性**。它靠的是 binlog 解析 + 模拟写入，而 MySQL 的 trigger 是在原始 DML 执行时由 server 层触发的——这两条路径完全不重叠。
常见错误现象：gh-ost 迁移后，业务侧发现数据不一致，查下来是原表上的 AFTER INSERT trigger 没在影子表上生效，或更糟：trigger 里写了 INSERT INTO original_table，导致循环写入、死锁、主从延迟暴增。
- 所有对原表的
INSERT/UPDATE/DELETE触发的 trigger，都不会在_gho表上自动复现 -
gh-ost不解析 trigger 定义，也不做任何模拟或迁移，连 warning 都不报（除非你显式加--allow-on-master并碰巧撞上冲突） - 如果你依赖 trigger 做审计日志、冗余写入、状态同步等，迁移期间这些逻辑会“消失”或“错位”
如何判断你的 schema change 是否受 trigger 影响
不是看有没有定义 trigger，而是看它是否参与了**业务关键路径的数据生成或校验逻辑**。比如：
-
BEFORE UPDATE中修改了updated_at或计算字段 → 迁移后该字段在_gho表中可能为 NULL 或旧值 -
AFTER INSERT向另一张表写日志或更新计数器 → 这些写入只会发生在原表，_gho表无感知，切表后日志断层 - trigger 中调用了存储函数或访问了其他表 →
gh-ost的 binlog replay 不会触发它们，且可能因事务隔离级别导致读取到过期快照
实操建议：运行 SHOW TRIGGERS WHERE `Table` = 'your_table';，逐条检查 Timing 和 Event 列，重点标出含 INSERT、UPDATE、SELECT 或跨表操作的 trigger。
绕过 trigger 风险的三种可行做法
没有“安全启用 trigger”的方案，只有“规避依赖”或“人工补救”。以下按实施成本从低到高排列：
- 停用相关 trigger：在
gh-ost开始前DROP TRIGGER，切表完成后再重建。适用于 trigger 仅用于历史兼容、非实时强依赖的场景 - 把 trigger 逻辑提到应用层：比如把自动生成
updated_at改成 ORM 或 SQL 中显式赋值；把日志写入改成双写应用逻辑。这是长期最可控的方式 - 用
--hooks补偿：在gh-ost的post-cut-overhook 里手动跑一次数据订正脚本，但无法覆盖迁移过程中的中间状态，只适合最终一致性可接受的 case
注意：--allow-on-master 不解决 trigger 问题，它只是允许你在主库直接运行 gh-ost（绕过 replica），反而会让 trigger 冲突更早暴露、更难回滚。
MySQL 8.0+ 的 partial rollback 与 gh-ost 的隐性冲突
MySQL 8.0 引入了 atomic DDL，但 gh-ost 的整个流程仍基于非原子的 DML 拆分。当原表有 trigger 且其中包含 INSERT ... SELECT 或调用 GET_LOCK() 等阻塞操作时，容易触发 ER_XA_RBINLOG_ERROR 或 Lock wait timeout exceeded ——这不是 gh-ost 报的错，而是 binlog apply 线程在重放时被 trigger 卡住。
这种错误不会中断 gh-ost 主流程，但会导致主从延迟持续上涨、甚至复制中断。排查时你会看到 Seconds_Behind_Master 突增，而 gh-ost 日志里只有零星的 Copying rows 提示，毫无异常感。
- 根本原因：trigger 执行上下文和
gh-ost的 binlog replay 线程共享同一套锁机制，但事务边界不一致 - 验证方法：在测试环境开启
performance_schema，查events_statements_history_long，过滤出耗时长的INSERT并关联 trigger 名称 - 临时缓解：降低
--max-load，避免 trigger 被高频触发；但治标不治本
真正麻烦的从来不是 trigger 存不存在，而是它有没有在你不注意的时候，悄悄改了某一行的某个字段，而这个字段恰好是下游服务做幂等或路由的关键依据。
