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 流水线校验”。这类逻辑对象一旦失控，比数据丢失更难追溯。
