存储过程迁移后丢失，根本原因是mysqldump默认不导出存储过程，必须显式添加--routines参数；若未加该参数，备份文件中不含create procedure语句，恢复后必然缺失。
存储过程在 MySQL 迁移后丢失，大概率不是“丢了”，而是根本没导出或导入失败——mysqldump 默认不导出存储过程，除非显式加参数。
mysqldump 导出时没加 --routines 参数
这是最常见原因。默认情况下 mysqldump 只导出表结构和数据，CREATE PROCEDURE、CREATE FUNCTION 等不会包含在 SQL 文件里。
- 正确导出命令必须带
--routines（同时建议加--triggers和--events）：mysqldump -u root -p --routines --triggers --events database_name > backup.sql - 如果用的是
--all-databases，同样要加--routines，否则所有库的存储过程全都不导出 - 检查已有备份文件是否含
CREATE PROCEDURE：用grep -n "CREATE PROCEDURE" backup.sql，没结果就确认没导出
导入时权限不足导致创建失败
即使 SQL 文件里有 CREATE PROCEDURE 语句，导入时也可能静默跳过——MySQL 不报错，但过程没建成功。
- 导入用户必须有
CREATE ROUTINE权限，仅CREATE或ALTER不够 - 执行授权：
GRANT CREATE ROUTINE ON database_name.* TO 'username'@'host'; FLUSH PRIVILEGES; - 导入前先登录验证：
SHOW GRANTS FOR 'username'@'host';确认输出里含CREATE ROUTINE - 导入时加
-v（verbose）参数观察是否有 “Warning” 类提示，例如Warning: Skipping creation of routine xxx: Access denied
DELIMITER 在导入时被忽略
存储过程定义里常含分号（;），而 MySQL 客户端默认以分号为语句结束符，会导致 CREATE PROCEDURE 被截断解析，只执行到第一个分号就报错或跳过。
- 导出文件中应有
DELIMITER $$和结尾的$$，而不是纯分号 - 若手动编辑过备份文件，删掉了
DELIMITER块，导入就会失败 - 临时修复方法：导入前用 sed 替换（Linux/macOS）：
sed -i 's/DELIMITER ;/DELIMITER $$/g' backup.sql，再确保所有过程体结尾是$$而非; - 更稳妥做法：用
mysql客户端而非 shell 重定向导入，它能更好处理 DELIMITER（即source backup.sql）
目标 MySQL 版本禁用 stored_programs
极少数情况：目标实例开启了 log_bin_trust_function_creators=OFF 且过程含不确定函数（如 NOW()、UUID()），或 MySQL 8.0+ 中 secure_file_priv 限制了读写路径，导致过程创建被拒绝。
- 检查变量：
SELECT @@log_bin_trust_function_creators, @@secure_file_priv; - 若为 0，临时设为 1（需 SUPER 权限）：
SET GLOBAL log_bin_trust_function_creators = 1; - 注意：该设置重启失效，生产环境应评估风险后写入配置文件
恢复存储过程的核心不在“找回来”，而在“重跑一遍”。只要原始逻辑还在、权限和语法没问题，CREATE PROCEDURE 就能重建；真正难的是确认哪些过程该存在、参数和逻辑是否与线上一致——所以日常导出必须带 --routines，且定期验证备份文件可执行性。
