MySQL升级后存储过程和函数绝大多数仍可用，但需确保语法兼容、DEFINER用户存在、未使用废弃特性；验证须逐个调用而非仅查元数据表。
MySQL 升级后存储过程和函数是否自动可用
绝大多数情况下，升级后原有存储过程和函数仍可调用，但前提是它们的定义语法在新版本中仍被支持，且不依赖已被移除或行为变更的特性。MySQL 的兼容性策略是“尽量不破坏已有对象”，但不是绝对保证。
常见失效场景包括：
-
DEFINER用户在新实例中不存在，会导致调用时报ERROR 1449 (HY000): The user specified as a definer ('u'@'%') does not exist - 使用了已废弃的 SQL 模式（如
NO_AUTO_CREATE_USER）或函数（如OLD_PASSWORD()） - 存储过程内含
PRECEDES/FOLLOWS子句（仅限 MySQL 8.0.1+ 的事件调度器，旧版过程若误写会报错） - 函数声明为
DETERMINISTIC但实际非确定性，在严格 SQL 模式下可能被拒绝执行
如何验证升级后所有 routine 是否有效
不能只查 mysql.proc 或 information_schema.routines——这些表只说明对象存在，不反映运行时可用性。必须逐个尝试加载元数据并触发简单调用。
推荐做法：
- 导出 routine 列表：
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys'); - 对每个 routine 执行
SHOW CREATE PROCEDURE/FUNCTION xxx，检查输出是否报错（如权限不足、语法解析失败） - 对无参函数可直接
SELECT func_name();；对有参或复杂逻辑的，至少执行CALL proc_name()并捕获错误（注意事务状态影响） - 特别关注
sql_mode差异：升级后默认模式常更严格（如新增STRICT_TRANS_TABLES），可能导致隐式类型转换失败
MySQL 5.7 → 8.0 迁移中最易踩的 routine 坑
MySQL 8.0 对 routine 的元数据存储、权限模型和解析逻辑做了底层重构，以下问题高频出现：
-
mysql.proc表被彻底弃用，所有 routine 元数据统一存于mysql.routines和mysql.parameters，依赖直接读取mysql.proc的监控脚本会失效 -
DEFINER必须存在且具备EXECUTE权限；若原库用DEFINER='root'@'localhost'但新实例 root 只允许 socket 登录，则调用失败 - 8.0 默认启用
caching_sha2_password认证插件，若 routine 内部用CONNECTION相关逻辑（极少见），可能因认证方式不匹配中断 - 部分系统函数行为微调，例如
JSON_EXTRACT()对非法路径的容错性降低，旧 routine 若传入未校验的 JSON 路径可能突然报错
安全迁移 routine 的实操建议
不要直接 dump + restore routine，而应走“导出定义 → 人工审查 → 按需改写 → 分批创建”流程。
- 用
mysqldump --no-data --routines --skip-triggers db_name导出 routine 定义，避免混入表数据 - 检查所有
CREATE PROCEDURE语句中的SQL SECURITY设置：若为DEFINER，确认对应用户已在目标实例中创建并授权；建议临时改为INVOKER测试兼容性 - 禁用
log_bin_trust_function_creators=1时，所有函数必须显式声明DETERMINISTIC/NO SQL/READS SQL DATA，否则创建失败 - 8.0 支持 routine 级别注释（
COMMENT属性），可用于标记迁移状态，例如COMMENT 'migrated-202405'
最麻烦的往往不是语法错误，而是 routine 在新版本下逻辑结果变了却没报错——比如时间函数受时区配置影响、排序规则（collation）升级导致字符串比较行为偏移。上线前务必在影子库跑真实业务 SQL 覆盖验证。
