导出存储过程定义应使用mysqldump --no-data --routines --skip-triggers database_name，而非仅用SHOW CREATE PROCEDURE，因其完整导出含DEFINER、SQL SECURITY及依赖上下文，避免生产环境因权限、用户缺失或调试语句导致创建失败。
导出存储过程定义时别只用 SHOW CREATE PROCEDURE
直接执行 SHOW CREATE PROCEDURE proc_name 看起来最简单，但容易漏掉依赖项和权限信息。它只返回过程体，不包含 DEFINER、SQL SECURITY 设置，也不检查该过程是否引用了其他函数、视图或表——而这些在生产环境可能不存在或权限不足。
更稳妥的做法是用 mysqldump --no-data --routines --skip-triggers database_name，它会导出所有存储过程（含 CREATE PROCEDURE 完整语句），并自动带上 DEFINER 和安全上下文。如果只想导出单个过程，可用 SELECT routine_definition FROM information_schema.routines WHERE routine_schema = 'db_name' AND routine_name = 'proc_name'，但必须手动补上 CREATE 头部和权限语句。
生产环境执行前必须验证 DEFINER 用户是否存在且有权限
测试环境的 DEFINER 往往是开发账号（如 'devuser'@'localhost'），但生产环境通常禁用本地登录，或该用户根本没被创建。一旦执行时遇到 Access denied for user 'devuser'@'localhost' (using password: YES)，过程会创建失败，且错误提示模糊。
- 先在生产库运行
SELECT user, host FROM mysql.user WHERE user = 'devuser';，确认用户存在 - 若不存在，要么改写导出的 SQL，把
DEFINER = 'devuser'@'localhost'替换为生产环境已有账号（如'appuser'@'%'），要么提前创建该用户并授权 - 特别注意：MySQL 8.0+ 默认启用
require_row_format或强密码策略，新建用户需显式指定IDENTIFIED WITH caching_sha2_password BY 'xxx'
避免跨环境参数差异导致执行失败
测试过程里常带调试用参数，比如硬编码的 IN p_debug TINYINT DEFAULT 1，或临时插入日志表 INSERT INTO debug_log ...。这些在生产环境要么无意义，要么因表不存在直接报错。
发布前务必做三件事：
- 删掉所有调试用
INSERT、SELECT日志语句 - 检查默认值是否合理：
DEFAULT NOW()在生产可能引发时区问题，建议统一用UTC_TIMESTAMP() - 确认过程内调用的表名、库名全为小写（Linux 生产环境默认区分大小写），避免出现
Table 'ERP.PRODUCTS' doesn't exist
上线后必须立刻验证输出参数与返回结果集结构
看起来过程创建成功，不代表业务能用。常见问题是：测试时用 CALL proc(@out); SELECT @out; 验证输出参数，但生产调用方实际依赖的是结果集（SELECT 语句返回的列），而过程里调整过字段顺序、别名或新增了列，导致应用层解析失败。
上线后第一件事不是跑业务逻辑，而是：
- 用相同输入参数执行一次，观察返回结果集的列名、类型、顺序是否与文档/历史版本一致
- 检查是否有未声明的
OUT参数被应用代码读取，但新版本里漏写了SET out_param = ... - 留意 MySQL 的
sql_mode差异：测试环境可能是宽松模式（STRICT_TRANS_TABLES关闭），生产开启后，过程里隐式类型转换会直接报错
SELECT 调试语句，也可能触发锁升级或执行计划突变。 
