SQL gh-ost 的 online schema change 与 trigger 依赖风险评估

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-over hook 里手动跑一次数据订正脚本，但无法覆盖迁移过程中的中间状态，只适合最终一致性可接受的 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 存不存在，而是它有没有在你不注意的时候，悄悄改了某一行的某个字段，而这个字段恰好是下游服务做幂等或路由的关键依据。