mysqldump 默认不导出触发器，必须显式添加 --triggers 参数；--all-databases 下自动启用，但指定库备份时默认关闭，恢复前需检查 dump 文件是否含 create trigger 语句。
触发器在 mysqldump 备份时默认不导出
mysqldump 默认只导出表结构、数据和存储过程，TRIGGER 权限虽影响能否创建触发器，但 dump 本身不会包含 CREATE TRIGGER 语句——除非显式加参数。没这个意识，恢复后表存在、触发器消失，业务逻辑就断了。
- 必须加
--triggers参数才能导出触发器定义（注意：不是--routines，后者只管函数/存储过程） - 若用
--all-databases，--triggers会自动生效；但指定库名备份时，它默认关闭 - 恢复前检查 dump 文件里有没有
DELIMITER $$和CREATE TRIGGER块，没有就是漏了
恢复时触发器执行时机可能破坏数据一致性
触发器在 INSERT/UPDATE/DELETE 执行时自动触发，而 dump 恢复本质是一批 INSERT 语句。如果触发器含业务校验、跨表更新或调用函数，恢复过程可能报错或写入脏数据。
- 生产环境恢复前，建议临时禁用触发器：
SET @OLD_SQL_MODE=@@SQL_MODE; SET SQL_MODE='NO_AUTO_VALUE_ON_ZERO';不够，得靠SET SQL_LOG_BIN=0;+ 关闭 binlog（仅限从库或离线恢复） - 更稳妥做法：dump 后手动注释掉 dump 文件中的触发器定义，恢复完成再单独执行
CREATE TRIGGER - 特别警惕
AFTER INSERT触发器写日志表——恢复大量历史数据时，日志表会暴涨，甚至阻塞主键冲突检测
主从复制中触发器行为不一致是常见坑点
MySQL 默认在从库重放主库的原始 SQL（STATEMENT 格式），但触发器只在执行端本地触发。也就是说：主库上 INSERT 触发了 A 表插入 + B 表更新；从库回放这条 INSERT 时，A 表插入成功，B 表更新也发生——看起来一致。可一旦切换为 ROW 格式，从库只收到 A 表变更，B 表不会被触发更新，数据就裂开了。
- ROW 格式下，触发器在从库完全不执行，这是 MySQL 明确设计行为，不是 bug
- 如果业务依赖触发器维护衍生字段或关联表，必须用 STATEMENT 或 MIXED 日志格式，并确保所有触发器逻辑可安全重入
- 用
SHOW CREATE TABLE查触发器定义时，留意DEFINER用户是否存在——从库缺失该用户会导致恢复时报ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist
备份工具选型直接影响触发器处理可靠性
Percona XtraBackup 是物理备份，它直接拷贝 ibd 文件和触发器元数据（存于 mysql.triggers 系统表），只要备份时实例正常运行，触发器必然完整。而逻辑备份工具如 mydumper，默认也不导出触发器，需明确加 --triggers 开关。
-
mysqldump --triggers导出的是可读 SQL，适合审计；XtraBackup 备份快、不锁表，但恢复后需mysql_upgrade（5.7→8.0 升级场景）才确保mysql.triggers元数据兼容 - 云厂商 RDS 的“一键备份”多数封装了
--triggers，但自建环境千万别假设它默认开启 - 最隐蔽的坑：某些运维脚本用
mysqldump --no-create-info做增量数据导出，这种模式下--triggers完全无效——触发器根本不会出现在输出里
触发器不是黑盒，它是嵌入在 SQL 执行链路里的隐式逻辑。备份恢复时，它既可能默默保全数据一致性，也可能在无人察觉时悄悄撕开一道口子。关键不在“有没有”，而在“什么时候执行、在哪台机器上执行、以谁的身份执行”。
