恢复时触发器自动执行会破坏数据一致性，因mysqldump恢复本质是insert重放，after insert触发器逐条触发，导致日志/统计表重复写入、主键冲突、外键失败及now()/uuid()等函数引发主从不一致。
恢复时触发器自动执行会破坏数据一致性
mysqldump 恢复本质是一批 INSERT 语句重放，而 AFTER INSERT 触发器会在每条语句执行后立刻触发。如果触发器逻辑是“写日志表”或“更新统计表”，恢复 10 万行数据就会引发 10 万次额外写入——不仅慢，还可能因主键冲突、外键校验失败或时间函数（如 NOW()）导致主从不一致。
- 典型错误现象：
ERROR 1062 (23000): Duplicate entry 'xxx' for key 'PRIMARY'（日志表主键重复）、ERROR 1452 (23000): Cannot add or update a child row（外键约束失败） - 即使用了
--triggers参数导出触发器，恢复时也默认启用它们——MySQL 不会自动跳过或降级 - 触发器中调用
UUID()、RAND()或依赖连接上下文的变量（如USER()），在恢复过程中生成的值与原始数据无关，纯属干扰
恢复前必须禁用触发器或剥离定义
直接在恢复命令里加 SET SQL_LOG_BIN = 0 不起作用——它只关 binlog，不影响触发器本身执行。真正可行的路径只有两条，且必须二选一：
-
推荐做法：手动注释掉 dump 文件中的触发器块，用
sed -i '/^CREATE TRIGGER/,/^DELIMITER ;/s/^/-- /' backup.sql批量注释（注意确认DELIMITER结束行是否为独立一行） - 临时禁用：在恢复会话开头执行
SET @OLD_SQL_MODE=@@SQL_MODE; SET SQL_MODE='NO_AUTO_VALUE_ON_ZERO';不够；必须配合SET SESSION sql_log_bin = 0;+SET GLOBAL log_bin_trust_function_creators = 1;（仅限离线恢复环境） - 切勿在从库上执行
DROP TRIGGER后恢复——这会导致主从语义脱节，后续复制可能卡死
恢复完成后单独重建触发器要检查三件事
触发器不是建完就完事，CREATE TRIGGER 成功不代表它能正常工作。以下三点漏一个，上线后就静默失效：
-
DEFINER用户必须存在：若 dump 中是DEFINER=`admin`@`%`，而目标库没该用户，会报ERROR 1449 (HY000)；要么提前创建用户，要么用sed删除整段DEFINER=... - 触发器引用的对象必须已就位：比如触发器里调用了
FUNCTION calc_score()，该函数必须在CREATE TRIGGER前已存在，否则 MySQL 5.7+ 会静默跳过创建 - 触发器体内的表名和字段名，必须与当前表结构完全匹配：哪怕只是把
user_name改成name，CREATE TRIGGER就会报ERROR 1351 (HY000)这类误导性错误
用 mysqldump --skip-triggers 备份反而更安全
很多人迷信“备份要全”，但对触发器而言，--skip-triggers 是生产环境更可控的选择。它强制你把触发器当作独立部署单元管理，而不是和数据绑死。
- 备份时明确排除触发器，恢复时只操作数据，逻辑清晰、可预期
- 触发器定义单独存为
triggers.sql，用版本控制管理，每次上线前人工审核变更 - Percona XtraBackup 这类物理备份虽自带触发器元数据，但它无法区分“哪些触发器该恢复、哪些该跳过”，遇到跨环境迁移（如测试→生产）反而更难处理
最常被忽略的是：触发器恢复不是“有没有”的问题，而是“执行时机是否可控”的问题。只要恢复过程绕不开批量 DML，就必须把触发器当成外部副作用来隔离——否则一次 restore 就可能让业务多跑一周脏数据修复脚本。
