不加--routines参数，mysqldump绝不会导出存储过程；加了仍失败的主因是未指定数据库名、权限不足（需SELECT+SHOW ROUTINES）或严格SQL模式导致读取失败。
不加 --routines，mysqldump 绝对不会导出存储过程，哪怕你用 --all-databases 或指定了库名，过程照样丢得干干净净。
为什么加了 --routines 还是没导出？
常见原因有三个：
-
--routines必须和数据库名一起用，单独加它但漏掉--databases或库名（如mydb），命令会静默忽略该参数；正确写法是mysqldump -u root -p --routines --databases mydb > mydb_routines.sql - 执行账号缺少
SELECT权限或SHOW ROUTINES权限（MySQL 8.0+ 需显式授权：GRANT SHOW ROUTINES ON mydb.* TO 'user'@'host';） - 目标库启用了
sql_mode=STRICT_TRANS_TABLES等严格模式，而过程定义里用了未声明变量或模糊分组，mysqldump在读取mysql.proc时可能报错退出（现象是输出文件为空或只含报错头）
--routines 和 --triggers 能不能分开用？
可以，而且经常需要分开控制：
- 只导过程和函数：用
--routines，不加--triggers；触发器存在mysql.triggers表，不依赖此参数 - 只导触发器：必须加
--triggers，但注意——它默认只在导出整库或表时生效；如果只导结构（-d）或只导数据（-t），--triggers会被忽略 - 同时导过程和触发器：两个参数都加，且建议搭配
--no-data --no-create-info，避免混入无用的建表和插入语句
导出后导入失败的典型报错怎么快速定位？
导入时报错往往不是语法问题，而是权限/上下文不匹配：
-
ERROR 1418：目标 MySQL 8.0+ 的log_bin_trust_function_creators是OFF，需提前执行SET GLOBAL log_bin_trust_function_creators = 1; -
ERROR 1449：过程里DEFINER=`u1`@`%`，但目标库没有这个用户，或没给EXECUTE权限；用grep -n "DEFINER" mydb_routines.sql扫一遍，再查SELECT User,Host FROM mysql.user; -
ERROR 1064（JSON 函数报错）：源库是 MySQL 5.7.8+，目标库低于此版本；检查过程体是否含JSON_EXTRACT、JSON_CONTAINS等，低版本直接不识别
真正麻烦的不是导出命令本身，而是导出内容里的 DEFINER、SQL_MODE 和字符集隐式依赖——它们不会报错，但会让过程在目标库创建成功却调用失败。动手前先看一眼 SHOW CREATE PROCEDURE xxx\G 的实际定义，比死记参数有用得多。
