不加--routines和--triggers，mysqldump不会导出存储过程、函数或触发器，即使dump整个库也会静默遗漏；--routines控制函数与存储过程（默认关闭），--triggers控制触发器（全库场景必须显式声明），二者须配合--databases或库名使用，权限不足时静默跳过，可通过检查输出文件中是否存在CREATE FUNCTION确认是否生效。
不加 --routines 和 --triggers，mysqldump 就不会导出存储过程、函数或触发器——哪怕你 dump 的是整个库，逻辑层对象照样静默消失。这是生产事故高发区：表在，数据在，但 CALL update_cache() 报错“procedure does not exist”，或 INSERT 后统计字段没更新，问题根源全在这两个开关漏了。
必须显式启用 --routines 和 --triggers
这两个参数不是可选优化项，是功能开关：
-
--routines控制存储过程（PROCEDURE）和函数（FUNCTION），默认关闭；不加它，SHOW PROCEDURE STATUS在恢复后一定为空 -
--triggers控制触发器（TRIGGER），默认在单表 dump 时开启，但在全库或--databases场景下**必须显式声明**，否则可能因版本差异被跳过 - 二者必须和
--databases或具体库名一起用，单独加在mysqldump -u root -p --routines后面无效 - 权限不足时（如普通账号无权读
mysql.routines表），mysqldump 会静默跳过 routines，不报错——检查输出 SQL 文件里有没有CREATE FUNCTION就能验证是否生效
只导逻辑对象（不含表结构/数据）的正确组合
想单独备份存储过程和触发器，不是靠“排除”参数，而是靠精准裁剪输出内容：
- 仅 routines（函数 + 存储过程）：
mysqldump -u root -p --no-data --no-create-info --routines --skip-triggers mydb > routines.sql - 仅触发器？mysqldump 没有原生支持。正确做法是先全量导出（含
--triggers），再用grep -A 50 "CREATE DEFINER.*TRIGGER"提取，或改用mysqlpump --routines --exclude-tables=% mydb（MySQL 5.7+） -
--skip-triggers是禁用触发器导出，不是“只导触发器”——名字容易误导，务必注意 - 若目标库已存在表结构，只补逻辑对象，用
--no-create-info --no-data可避免重复建表或覆盖数据
DEFINER 导致恢复失败的处理方式
导出的 CREATE PROCEDURE 默认带 DEFINER=`user`@`host`，恢复时报 ERROR 1418 或 Access denied; you need the SUPER privilege，本质是权限继承失败，不是缺权限：
- 导出时直接剥离：MySQL 5.7.8+ 加
--skip-definer，生成语句自动省略 DEFINER 或设为DEFINER=CURRENT_USER - 老版本或需批量清理：用
sed 's/DEFINER=[^ ]* //g' backup.sql > clean.sql（注意别误删注释里的 DEFINER） - MySQL 8.0+ 迁移建议搭配
--set-gtid-purged=OFF，避免 GTID 冲突 - 别用
SET GLOBAL log_bin_trust_function_creators = 1临时绕过——它只对函数/过程有效，对触发器无效，且开了就忘关是安全隐患
恢复前必须确认的三件事
导入 routines.sql 或全量备份前，光执行 mysql -u root -p 不够：
- 目标用户要有
CREATE ROUTINE和CREATE TRIGGER权限（不是 SUPER） - 确保依赖的表结构已存在——触发器绑定在具体表上，若表还没建，
CREATE TRIGGER会直接报错退出 - 若过程体里用了
NOW()、RAND()或 JSON 函数，确认目标 MySQL 版本支持（如 JSON_EXTRACT 要求 5.7.8+） - 字符集不一致会导致函数体乱码，导出时务必加
--default-character-set=utf8mb4
真正麻烦的从来不是导出命令怎么写，而是恢复后调用时报错却查不到 DEFINER 字段在哪、或者发现触发器绑在一张被 rename 的旧表上——逻辑对象的隐式依赖，比表结构更难审计。
