mysqldump 默认不导出存储过程和触发器，必须显式添加 -R（--routines）和 -E（--triggers）参数；-R 依赖对 mysql.proc（5.7-）或 mysql.routines（8.0+）的 SELECT 权限，缺权限会静默跳过，且是否导出表数据由 -d、-t 等参数独立控制。
mysqldump 默认不导出存储过程，加 -R（或 --routines）才生效，但光加 -R 不代表“带数据”——它只控制是否把 CREATE PROCEDURE 和 CREATE FUNCTION 语句写进输出文件，和表数据无关。是否导出表数据，由 -d、-t 等参数独立控制。
为什么加了 -R 还没看到存储过程？
常见静默失败原因：
- 用户没有对
mysql.proc（5.7 及以前）或mysql.routines（8.0+）的SELECT权限 ——mysqldump不报错，直接跳过 routines 导出 - MySQL 8.0+ 默认禁用
log_bin_trust_function_creators，但该设置不影响mysqldump -R，仅影响函数创建；真正卡权限的是routines表本身 - 命令里漏了数据库名，例如
mysqldump -u root -p -R没指定库，会报错或导出空内容
导出「结构 + 数据 + 存储过程」的正确组合
要同时包含表结构、表数据、所有存储过程/函数，用以下任一写法均可：
-
mysqldump -u root -p -R myapp_db > full.sql（最简形式，默认含结构+数据+触发器，-R额外加 routines） -
mysqldump -u root -p --routines --triggers myapp_db > full.sql（显式写出，更易读） - 若需排除某些表，可用
--ignore-table=myapp_db.log_table，它不影响-R生效
注意：--triggers 默认开启，不用加也能导出触发器；但业务逻辑常和过程耦合，建议显式保留。
只想导出存储过程定义，不导表数据也不导表结构
这是高频误操作点：很多人以为 -R 自带“只导过程”，其实不是。必须配合 -n（不建库）、-d（无数据）、-t（无 INSERT）才能实现纯 routine 导出：
mysqldump -u root -p -R -ndt myapp_db > procedures_only.sql- 输出里只有
DELIMITER ;; CREATE PROCEDURE ... END ;;类语句，不含任何CREATE TABLE或INSERT - 若漏掉
-t，仍会导出表数据；若漏掉-d，仍会导出表结构
导入时容易被忽略的权限与顺序问题
导出文件能用 mysql -u root -p myapp_db 导入，但要注意：
- 目标库必须已存在（
CREATE DATABASE语句默认在 dump 文件开头，除非用了-n） - 如果过程里有
DEFINER=`user`@`host`，而目标环境没有该用户，导入会失败或自动降级为CURRENT_USER—— MySQL 8.0+ 默认行为更严格 - 触发器和过程依赖表结构，所以必须先建表再创建 routine；
mysqldump默认按此顺序输出，但手动拼接 SQL 时容易颠倒
最稳妥的做法是：导出用 -R -E -d（结构+routine+event+trigger），导入前确保库存在、用户权限就位，别指望 dump 文件能自动补权限。
