mysqldump --routines 能导出存储过程定义，因其显式启用routine导出开关，从information_schema.ROUTINES读取ROUTINE_DEFINITION并自动包裹DELIMITER $$/DELIMITER ;结构，避免分号被客户端提前解析。
直接用 mysqldump --routines 导出再导入，是最稳妥、最常用的方式，但必须注意 DELIMITER 和权限问题，否则导入会静默失败或只建空过程。
为什么 mysqldump --routines 能导出存储过程定义
mysqldump 默认不导出存储过程（routine）、函数、触发器等数据库对象，必须显式加 --routines 参数。它会从 information_schema.ROUTINES 表中读取 ROUTINE_DEFINITION，并自动包裹 DELIMITER $$ / $$ / DELIMITER ; 结构，避免过程体内的分号被 MySQL 客户端提前解析。
常见错误现象：没加 --routines，导入后查 information_schema.ROUTINES 返回空；加了但目标库用户没 CREATE ROUTINE 权限，导入时无报错但过程没创建成功。
- 必须加
--no-create-db，否则导出文件含CREATE DATABASE，导入时可能覆盖目标库名 - 若源库和目标库名不同，导出时用
--databases 源库名，导入时指定目标库名（mysql -u user -p 目标库名 ） - 导出命令示例：
mysqldump -u root -p --routines --no-create-db --no-data --no-create-info --databases source_db > sp_export.sql
导入前必须确认目标库用户的 routine 权限
MySQL 8.0+ 默认禁用 CREATE ROUTINE 权限，即使用户有 ALL PRIVILEGES，也不自动包含该权限。导入时若缺失，CREATE PROCEDURE 语句会被跳过，且 mysql 客户端默认不报错（除非加 -v 或检查返回值）。
验证方式：SHOW GRANTS FOR 'user'@'host';，确认含 GRANT CREATE ROUTINE ON *.* TO ...。
- 授予权限命令：
GRANT CREATE ROUTINE ON *.* TO 'target_user'@'%'; FLUSH PRIVILEGES; - 若仅需对单库授权，可改用
ON `目标库名`.*，但注意存储过程属于 schema 级对象，跨库调用时仍需对应库的 EXECUTE 权限 - 导入后务必验证：
SELECT ROUTINE_NAME FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = '目标库名' AND ROUTINE_TYPE = 'PROCEDURE';
导出文件里 DELIMITER 变更容易被忽略
mysqldump 生成的 SQL 文件开头通常有 DELIMITER $$，结尾有 DELIMITER ;，中间所有过程定义都用 $$ 结尾。这个机制是为了让客户端把整个 CREATE PROCEDURE ... END $$ 当作一条语句提交给服务端。
容易踩的坑：
- 手动编辑导出文件（比如替换库名）时误删了
DELIMITER $$或$$，导致导入时语法错误：ERROR 1064 (42000) - 在某些旧版 MySQL 客户端（如早期 phpMyAdmin）中，
DELIMITER不被识别，需改用其他分隔符或分段执行 - 如果目标 MySQL 版本启用了
sql_mode=STRICT_TRANS_TABLES，而过程体里有隐式类型转换，可能导入成功但后续调用时报错
真正麻烦的不是导出，而是导入后过程能创建却不能执行——比如依赖的表、函数、甚至系统变量（如 log_bin_trust_function_creators）在目标环境缺失。这类问题不会在 mysqldump 流程里暴露，得靠调用测试才能发现。
