mysqldump 默认不导出函数、存储过程和触发器，需显式添加–routines和–triggers参数；全库备份推荐使用–all-databases –routines –triggers；触发器definer问题可通过–skip-definer解决；单独导出可用show create语句；生产中触发器存在级联、事务耦合、权限放大等隐患。
mysqldump 能否直接备份函数和触发器
默认情况下 mysqldump 不导出存储函数、存储过程、触发器，除非显式启用对应参数。这是很多运维人员漏掉备份逻辑对象的根源。
必须加上这两个关键选项：
-
--routines：导出function和PROCEDURE -
--triggers：导出TRIGGER（注意：该选项默认开启，但仅在指定具体表时生效；全库备份时仍需显式声明以防版本差异）
推荐全库备份命令：
mysqldump -u root -p --all-databases --routines --triggers --events > full_backup.sql若只备份某库，且含触发器，务必写明库名+表名或用 --databases：
mysqldump -u root -p --databases myapp --routines --triggers > myapp_logic.sql触发器定义中 DEFINER 问题导致恢复失败
MySQL 导出的触发器语句默认带 DEFINER=`user`@`host`，恢复时若目标实例不存在该用户，或权限不足，会报错：Error 1418 (HY000): this function has none of DETERMINISTIC, NO SQL, or READS SQL DATA 或更直接的 access denied。
解决方法分两步：
- 导出时加
--skip-definer（5.7.8+ 支持），让 mysqldump 自动替换为DEFINER=CURRENT_USER - 或导入前手动替换 SQL 文件中的
DEFINER=`.*?`@`.*?`为DEFINER=CURRENT_USER（用 sed 或 vim %s 实现） - 临时放宽 SQL 模式（不推荐长期使用）：
SET GLOBAL log_bin_trust_function_creators = 1;，仅对函数/过程有效，不影响触发器
如何单独导出/验证某个触发器或函数
不依赖完整 dump，快速提取单个逻辑对象，适合变更审计或灰度验证：
- 查触发器定义：
SHOW CREATE TRIGGER db_name.trigger_name; - 查函数定义：
SHOW CREATE FUNCTION db_name.func_name; - 导出结果可重定向保存，例如：
mysql -u root -p -e "SHOW CREATE TRIGGER myapp.t_log_insert;" > trigger_t_log_insert.sql
注意：SHOW CREATE 返回的是可执行语句，但不含 DELIMITER —— 若函数体含分号，直接执行会报错，需人工补上 DELIMITER $$ 和结尾 $$。
生产环境触发器带来的安全与性能隐患
触发器不是“设了就完事”，它隐式绑定在 DML 上，容易被忽视却造成严重后果：
- 级联触发：A 表 INSERT 触发 B 表 UPDATE，B 表 UPDATE 又触发 C 表 INSERT，形成隐式链路，排查困难
- 事务耦合：触发器内操作失败会导致主语句回滚，但错误信息常不明确，日志里只显示 “statement aborted”
- 权限放大：触发器以
DEFINER权限执行，若用高权限账号创建，可能绕过应用层最小权限原则 - 无备份意识：开发提交 SQL 时很少同步更新备份脚本，上线后 dba 不知情，故障恢复时逻辑缺失
真正关键的不是“怎么备份”，而是“谁负责确认触发器存在、是否启用、是否有副作用、是否纳入 CI/CD 流水线校验”。这类逻辑对象一旦失控，比数据丢失更难追溯。