mysqldump 默认不导出存储过程和触发器，需显式添加 -R（--routines）和 -E（--triggers）参数；二者分别依赖 SELECT 权限访问系统表，且还原时需注意 DEFINER、版本兼容性及对象冲突问题。
mysqldump 默认不导出存储过程和触发器
直接执行 mysqldump -u root -p db_name 不会包含 CREATE PROCEDURE、CREATE FUNCTION、CREATE TRIGGER 语句——这是很多人备份后还原失败的根源。MySQL 默认只导出表结构（CREATE TABLE）和数据，过程、函数、触发器被完全跳过。
根本原因在于权限与安全策略：这些对象属于“程序性逻辑”，需显式启用导出开关，否则 mysqldump 为兼容旧版本和最小权限场景，默认禁用。
--routines（-R）参数：导出存储过程和函数
--routines（简写为 -R）告诉 mysqldump 把数据库中所有 PROCEDURE 和 FUNCTION 的定义一并写入输出 SQL 文件。
- 必须有
SELECT权限在mysql.proc表（MySQL 5.7 及以前）或mysql.routines（8.0+），普通用户常因缺此权限而静默失败 - 导出内容是
CREATE PROCEDURE/CREATE FUNCTION语句，不含调用逻辑或运行时状态 - 若只想导出某几个过程，
mysqldump不支持按名过滤，得靠后续grep或脚本提取 - 示例命令：
mysqldump -u root -p -R --no-data myapp_db > schema_with_routines.sql（加--no-data可只导结构+过程，不导表数据）
--triggers（-E）参数：导出触发器
--triggers（简写为 -E）控制是否导出触发器。注意：它**不依赖** -R，可单独使用；但实际中几乎总和 -R 一起用，因为业务逻辑常耦合过程与触发器。
- 触发器绑定在具体表上，
mysqldump会在对应CREATE TABLE语句后插入CREATE TRIGGER块 - 若目标库已存在同名触发器，还原时会报错
ERROR 1359 (HY000): Trigger already exists，需手动DROP TRIGGER或加--add-drop-trigger - MySQL 5.7+ 中，触发器定义存于
information_schema.TRIGGERS，需要SELECT权限；低版本需TRIGGER权限 - 常见组合命令：
mysqldump -u root -p -R -E myapp_db > full_backup.sql
容易被忽略的权限与还原陷阱
即使加了 -R 和 -E，备份文件也可能“看起来正常却无法还原”——问题往往不在参数本身，而在执行上下文。
- 备份时用户缺少
SELECT权限访问mysql.proc或information_schema.TRIGGERS→ 输出里没有过程/触发器语句，且无任何警告 - 还原时目标 MySQL 版本低于源库（如从 8.0 备份还原到 5.7）→ 某些过程语法（如 CTE 在过程体中）不兼容，报错位置指向过程定义开头
- 还原前未清理旧对象 → 触发器名冲突、过程名重复，报错
ERROR 1304 (42000): PROCEDURE xxx already exists，此时需加--add-drop-procedure和--add-drop-trigger -
DEFINER存在风险：导出的CREATE PROCEDURE含DEFINER=`user`@`host`，若目标库无该用户，还原会失败或降级为CURRENT_USER，行为可能改变
真正稳妥的做法不是只记参数，而是每次备份后快速验证：打开 SQL 文件搜 CREATE PROCEDURE 和 CREATE TRIGGER，确认数量匹配，再检查开头是否有 DELIMITER 块——缺失它，还原时会因分号提前截断而报语法错误。
