mysqldump默认不导出触发器，必须显式加--triggers参数；仅当按库导出且用户具备trigger权限时才可能包含，但仍有被--no-create-info或权限不足等导致静默跳过风险，验证需确认backup.sql中同时存在delimiter和create trigger语句。
mysqldump 默认到底导不导触发器？
默认会导，但有个关键前提：你得用 mysqldump -u user -p db_name 这种「按库导出」的方式，且用户必须有 TRIGGER 权限。如果用了 --no-create-info 或 --skip-triggers，或者只导部分表却没确认触发器绑定在哪张表上，那触发器就没了。
验证是否导出成功，打开 backup.sql 搜索 CREATE TRIGGER 和 DELIMITER —— 两者都得有，缺一不可。只看到 DELIMITER 没 CREATE TRIGGER，说明权限不足或参数被意外关闭。
只备份触发器，不备份表和数据，怎么操作？
mysqldump 没有原生「仅触发器」开关，但可以用组合参数逼近：
-
mysqldump -u root -p --no-create-info --no-data --triggers --routines db_name > triggers_only.sql—— 注意：--routines会把存储过程也带上，不是纯触发器 - 更干净的做法是先全量导出：
mysqldump -u root -p --triggers --routines db_name > full.sql，再用grep -A 50 "CREATE DEFINER.*TRIGGER" full.sql > triggers.sql提取 - MySQL 5.7+ 可用
mysqlpump：mysqlpump --exclude-tables=% --routines --triggers db_name > triggers.sql，它支持真正排除表
恢复后触发器没生效，常见原因有哪些？
导入命令没报错 ≠ 触发器已创建。容易忽略的几个点：
- 目标库用户缺少
TRIGGER权限 —— 执行SHOW GRANTS FOR CURRENT_USER;确认输出含TRIGGER -
DEFINER用户不存在（比如备份里是DEFINER=`admin`@`192.168.%`，但目标库没这个账号）—— 恢复前用sed -i 's/DEFINER=[^ ]*//g' backup.sql剥离 - 触发器依赖的表还没建好 —— 必须先恢复表结构，再导入触发器语句；若用
mysqldump --no-data导出结构，要确保它包含触发器定义 - 客户端连接字符集不匹配（如备份用
utf8mb4，导入时character_set_client是latin1），会导致DELIMITER解析失败，整段触发器被跳过
误删触发器后，从备份里怎么精准还原？
别全量恢复数据库，直接提取并重执行定义即可：
- 在
backup.sql里定位对应触发器：搜索CREATE TRIGGER trigger_name，注意它前面通常有DELIMITER ;;，后面有DELIMITER ; - 复制从
DELIMITER ;;开始到下一个DELIMITER ;结束的完整块（含中间所有语句） - 在目标库执行：
mysql -u user -p db_name -e "DELIMITER ;; CREATE TRIGGER ... ;; DELIMITER ;"—— 关键是手动指定DELIMITER，避免客户端自动换行截断 - 验证是否生效：
SHOW TRIGGERS FROM db_name LIKE 'trigger_name';，看Status是否为ENABLED
真正麻烦的不是找语句，而是触发器内部引用了其他对象（比如函数、临时表、特定字段），这些依赖必须提前存在，否则 CREATE TRIGGER 会静默失败 —— 最好在测试库先试跑一遍。
