触发器备份后数据不一致，根本原因在于还原时被重复执行、跳过执行或执行环境错配：mysqldump默认跳过触发器（5.7+启用--skip-triggers），须显式加--triggers；即使导出，DEFINER用户缺失、SQL SECURITY为DEFINER且权限不足、含UUID()/NOW()等非确定性函数，均导致行为偏差；还原还受binlog位点、事务一致性及写入并发影响，修复前须验证information_schema.TRIGGERS是否存在、逐字比对SHOW CREATE TRIGGER定义、检查还原命令是否误含--skip-triggers。
触发器备份后数据不一致，不是备份工具“漏了内容”，而是触发器本身在还原时被重复执行、跳过执行，或执行环境与原库不匹配——mysqldump 默认就跳过触发器，即使导出了，DEFINER 用户不存在、SQL SECURITY 不同、@var 或 UUID() 等非确定性逻辑也会让还原结果和原库对不上。
mysqldump 默认不导出触发器
MySQL 5.7+ 版本起，mysqldump 默认启用 --skip-triggers，哪怕你写了 --all-databases，也不会把 CREATE TRIGGER 语句写进备份文件。结果就是：导入后表结构和数据都有，但触发逻辑完全丢失。
- 必须显式加
--triggers参数：例如mysqldump --triggers -u root -p mydb > backup.sql - 导出后立刻验证：
grep "CREATE TRIGGER" backup.sql，确认有且仅有一段有效定义 - 别信“我用了
--routines就够了”——存储过程和触发器是两回事，--routines不管触发器
还原时触发器执行环境错配
就算备份里有 CREATE TRIGGER，导入目标库后也可能不生效，或行为异常。常见原因不是语法报错，而是运行时权限和上下文不一致。
-
DEFINER用户在目标库不存在 → 导入时报ERROR 1449，但部分客户端会静默跳过整条语句 -
SQL SECURITY是DEFINER，而目标库该用户没TRIGGER权限 → 触发器加载失败，SHOW TRIGGERS查不到，也不报错 - 触发器内用了
@tmp、UUID()、NOW()→ 还原时这些值全按目标库时间/会话生成，和原库快照对不上
备份还原过程破坏触发器一致性锚点
触发器依赖的不只是代码，还有 binlog 位点、事务边界、甚至主从复制状态。一次不严谨的备份还原，可能直接切断这个链条。
- 没用
--master-data=2→ 还原后无法准确定位 binlog 起点，后续复制起点错，触发器变更根本不同步 - 用了
--single-transaction但库中有 MyISAM 表 → 非事务表快照时间点不一致，触发器读到的关联数据是“半新鲜”状态 - 还原前没停写入 + 没加锁 → 触发器在导入过程中被应用层调用，导致中间态写入和备份快照冲突
修复前必须确认的三件事
别急着跑 pt-table-sync 或手动 UPDATE，先看清楚问题出在哪一层：
- 查目标库是否真加载了触发器：
SELECT * FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'mydb';，为空就说明没加载成功 - 比对
SHOW CREATE TRIGGER t_name在源库和目标库的输出，逐字核对DEFINER、SQL SECURITY、字符集、注释换行符 - 检查还原命令是否带
--skip-triggers（比如某些运维脚本硬编码了它），或是否被mysql客户端配置自动追加
真正难的不是补一条 DROP 再 CREATE，而是判断哪一行触发逻辑在哪个环节被悄悄绕过了——DEFINER 缺失不会报错，SQL_LOG_BIN=0 下触发器照常运行但不记日志，slave_exec_mode=IDEMPOTENT 会让失败更新静默吞掉。这些都得靠查运行时值，不能只看配置或备份文件内容。
