mysqldump 默认不备份触发器和存储过程？
默认情况下，
mysqldump会跳过触发器（TRIGGERS）和存储过程（ROUTINES），除非显式启用对应选项。这是很多备份失效的根源——表数据回来了，但
INSERT后自动更新统计的触发器没了，或者应用调用的
CALL calc_total()报错“procedure does not exist”。
关键参数只有两个：
--triggers和
--routines。前者控制触发器（默认开启，但仅在 dump 表时附带；若用
--no-create-info就会被连带禁用），后者默认关闭，必须手动加。
mysqldump -u root -p --routines --triggers mydb > backup.sql如果只导出存储过程/函数，不导表：加
--no-create-info --no-data，再配合
--routines注意：
--routines会同时导出存储过程（PROCEDURE）和函数（FUNCTION），无法单独筛选
恢复时提示 “Access denied; you need the SUPER privilege”
这是因为存储过程/函数定义中包含
DEFINER='user'@'host'，而目标库用户没有
SUPER权限（MySQL 5.7+ 默认禁用，8.0+ 彻底移除
SUPER）。直接执行
source backup.sql会失败。
解决方法不是提权，而是剥离或重写
DEFINER： dump 时加
--skip-definer（MySQL 5.7.8+ 支持），生成的 SQL 自动替换为
DEFINER=CURRENT_USER或用 sed 预处理：
sed 's/DEFINER[^\*]*\*/\*/g' backup.sql > clean.sqlMySQL 8.0+ 更推荐用
--set-gtid-purged=OFF配合
--skip-definer，避免 GTID 冲突
只备份触发器或只备份存储过程，怎么操作？
没有原生命令直出“仅触发器”，但可通过组合参数逼近：
只导触发器：用mysqldump -u root -p --no-create-info --no-data --triggers --routines --skip-triggers your_db不行——
--skip-triggers会关掉它。正确做法是导全量后用文本提取：
grep -A 20 "CREATE DEFINER.*TRIGGER" backup.sql只导存储过程：加
--no-create-info --no-data --routines，再用
grep -E "^(DELIMITER|CREATE (PROCEDURE|FUNCTION))"过滤 真正隔离依赖建议用
mysqlpump（MySQL 5.7+）：
mysqlpump --routines --exclude-tables=% mydb可排除所有表，只留 routine
mysqldump 备份后，恢复发现触发器没生效
常见原因不是 dump 缺失，而是恢复顺序或权限问题：
触发器绑定在某张表上，但恢复时先执行了DROP TABLE、再建表、最后导入触发器 —— 若中间有
SET FOREIGN_KEY_CHECKS=0或事务中断，触发器可能被跳过 确认
backup.sql中触发器语句是否真实存在：搜索
CREATE TRIGGER，检查是否被注释或包裹在条件逻辑里 恢复后手动验证：
SELECT TRIGGER_NAME FROM INFORMATION_SCHEMA.TRIGGERS WHERE TRIGGER_SCHEMA='mydb';MySQL 8.0+ 注意：若源库用的是
utf8mb4_0900_as_cs排序规则，而目标库是
utf8mb4_general_ci，
CREATE TRIGGER可能因字符集不兼容静默失败 实际备份命令建议以这句为准：
mysqldump -u root -p --routines --triggers --skip-definer --set-gtid-purged=OFF mydb > full_backup.sql。别漏掉
--skip-definer，这个选项在跨环境迁移时几乎必用。
