mysqldump导出存储过程和函数必须显式加--routines参数，否则默认仅导出表结构和数据，导入后SHOW PROCEDURE STATUS为空且调用报错“PROCEDURE does not exist”。
mysqldump 导出时必须加 --routines 参数
默认情况下 mysqldump 不导出存储过程、函数、触发器和事件，只导出表结构和数据。如果漏掉这个参数，导入后 SHOW PROCEDURE STATUS 会为空，应用调用直接报错 PROCEDURE xxx does not exist。
正确命令示例：
mysqldump -u root -p --all-databases --routines --triggers --events --single-transaction > full_dump.sql
-
--routines：导出所有存储过程和函数 -
--triggers：导出触发器（常与存储过程联动） -
--events：导出事件调度器（若过程被定时调用） -
--single-transaction：避免锁表，保证导出一致性（仅对 InnoDB 有效）
目标服务器需启用 log_bin 和 log_bin_trust_function_creators
导入含存储过程的 SQL 文件时，MySQL 默认禁止创建可能影响复制安全性的函数或过程，会报错：This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration 或 ERROR 1418。
解决方法是提前在目标服务器的 my.cnf 中配置：
[mysqld] log_bin = mysql-bin log_bin_trust_function_creators = 1
然后重启 MySQL：
systemctl restart mysqld
注意：log_bin 必须存在（即使不用于主从），否则 log_bin_trust_function_creators 不生效；该配置仅在导入阶段需要，后续可按需关闭，但生产环境建议保留。
字符集不一致会导致 CREATE PROCEDURE 语法解析失败
如果源库用 utf8mb4 而目标库默认字符集是 latin1，mysqldump 生成的 CREATE PROCEDURE 语句里中文注释或变量名可能被截断或乱码，导入时直接报语法错误。
验证方式：
mysql -u root -p -e "SHOW VARIABLES LIKE 'character_set%';"
关键项必须一致：
character_set_servercollation_server- 每个数据库的默认字符集（查
information_schema.SCHEMATA）
修复建议：迁移前统一设为目标库支持的字符集，例如在 my.cnf 加：
[mysqld] character_set_server = utf8mb4 collation_server = utf8mb4_0900_ai_ci
导入后需手动校验过程定义是否完整
即使导入成功，也不能保证所有过程都可用。常见问题包括：
- 过程内调用的表或视图在目标库不存在（比如跨库引用未同步）
- 过程依赖的自定义函数未被导出（
--routines只导出当前库的 routine，跨库函数需单独处理） - 权限不足导致执行时报
EXECUTE command denied
快速校验命令：
mysql -u root -p -e "SELECT ROUTINE_NAME, ROUTINE_TYPE, DEFINER FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'your_db';"
再挑几个关键过程，用 SHOW CREATE PROCEDURE proc_name\G 对比源库输出，确认 body 内容无截断、无乱码、无缺失。
真正容易被忽略的是过程内部的硬编码库名或服务器地址——这些不会报错，但运行时逻辑就偏了。必须人工抽检逻辑路径，不能只看“导入成功”。
