mysqldump默认不导出存储过程、函数、触发器和事件，必须显式添加--routines（存储过程和函数）和--triggers（触发器）参数，否则恢复后业务逻辑中断；二者需配合--databases或库名使用，且权限不足时静默跳过。
备份存储过程不能只靠 mysqldump 默认行为——它默认不导出存储过程、函数、触发器和事件，除非显式启用对应参数。否则恢复时会丢失这些对象，业务逻辑直接中断。
mysqldump 必须加 --routines 参数
mysqldump 默认只导出表结构和数据，--routines 才会把 CREATE PROCEDURE 和 CREATE FUNCTION 语句写进备份文件。漏掉这个参数，备份文件里根本看不到存储过程定义。
- 正确命令：
mysqldump -u root -p --routines --no-create-info --no-data mydb > procedures_only.sql -
--no-create-info排除建表语句，--no-data排除数据，聚焦在过程/函数本身 - 若要连同表结构和数据一起备份，去掉这两个参数，但必须保留
--routines - 注意：
--routines对 MySQL 5.5+ 有效；MySQL 8.0 还需确认用户有SELECT权限在mysql.proc或information_schema.routines
恢复时权限和 DEFINER 问题最常导致失败
存储过程创建语句里带 DEFINER='user'@'host'，恢复时若目标库不存在该用户，或当前登录用户无 SET USER 权限，会报错 ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation。
- 方案一（推荐）：备份时加
--skip-definer，让mysqldump自动替换为DEFINER=CURRENT_USER - 方案二：恢复前手动替换备份文件里的
DEFINER行，或用sed -i 's/DEFINER=`[^`]*`@`[^`]*`//g' procedures_only.sql - 方案三：确保恢复用户有
SUPER或SET_USER_ID权限（MySQL 8.0+），但生产环境通常禁用SUPER
验证备份是否真包含存储过程
别等恢复失败才检查——打开备份文件搜 CREATE PROCEDURE 或 DELIMITER，但更可靠的是用命令快速确认：
-
grep -c "CREATE PROCEDURE" procedures_only.sql—— 返回大于 0 才算成功捕获 -
mysql -u root -p -D mydb -e "SHOW PROCEDURE STATUS WHERE Db='mydb'" | wc -l—— 先查源库有几个过程，再比对备份文件行数 - 如果备份文件里只有
CREATE TABLE没有CREATE PROCEDURE，一定是漏了--routines
存储过程不是“附带产物”，它是独立的数据库对象，mysqldump 默认忽略它。哪怕你备份了整库，只要没加 --routines，恢复后过程就消失了——而这种缺失往往在调用时报错才暴露，那时已晚。
