MySQL 5.7 存储过程无法直接在 8.0 正常运行，主因是权限模型变更、系统表结构不兼容及 SQL_MODE 行为差异；CREATE 成功但 CALL 报错常见于权限不足或 log_bin_trust_function_creators 关闭；DEFINER 校验更严格；PASSWORD() 等函数被移除；GROUP BY、字符集、游标处理等行为变化需适配；迁移后须实测执行路径、错误处理与事务边界。
MySQL 5.7 的存储过程不能直接导入 8.0 运行，核心问题不是语法报错，而是权限模型变更 + 系统表结构不兼容 + SQL_MODE 行为差异导致运行时失败或结果异常。
为什么 CREATE PROCEDURE 语句在 8.0 里执行成功但调用就报错
常见现象是 CREATE PROCEDURE 无报错，但 CALL proc_name() 报 ERROR 1370 (42000): execute command denied to user 或 ERROR 1418 (HY000)。根本原因是：5.7 中用户可能仅被授予 EXECUTE 权限，而 8.0 要求调用者还必须拥有对过程中所访问表的显式权限（哪怕只是 SELECT），且 log_bin_trust_function_creators 默认为 OFF。
- 检查过程内涉及的所有表，确保调用用户有对应权限（
SELECT、UPDATE等） - 临时启用信任模式（仅测试环境）：
SET GLOBAL log_bin_trust_function_creators = 1 - 生产环境必须改代码：把权限检查逻辑从“过程内判断”改为“调用前校验”，或统一用 DEFINER 用户执行
DEFINER 和 SQL SECURITY 在 8.0 中的行为变化
5.7 允许 DEFINER='root'@'%' 即使该用户不存在也能创建过程；8.0 会严格校验 DEFINER 是否存在、是否具备过程内操作所需的权限，且 SQL SECURITY DEFINER 下的权限检查发生在执行时刻而非创建时刻。
- 导出时用
mysqldump --routines --no-create-info获取过程定义，手动删掉原DEFINER子句 - 导入前先在 8.0 创建好同名用户，并确保其具备过程所需全部权限
- 显式指定
SQL SECURITY DEFINER或SQL SECURITY INVOKER，不要依赖默认值 - 避免使用通配符 host（如
'user'@'%'），8.0 对 host 匹配更严格，建议用具体 IP 或'user'@'localhost'
过程体内的语法和函数兼容性雷区
不是所有 5.7 可用的函数和写法在 8.0 都能安全执行。最常踩坑的是密码相关函数、字符集隐式转换、以及 GROUP BY 行为变化影响过程逻辑。
-
PASSWORD()函数在 8.0 已移除，若过程里有类似INSERT INTO users VALUES(PASSWORD('xxx'))，必须替换为SHA2('xxx', 256)或调用VALIDATE_PASSWORD_STRENGTH() - 过程里含
GROUP BY且依赖隐式排序（如SELECT id FROM t GROUP BY status ORDER BY id），8.0 会报错或返回非预期顺序，需显式加ORDER BY - 过程参数或变量声明为
CHAR未指定长度（如DECLARE v_name CHAR;），8.0 会报ERROR 1064，必须写成CHAR(1) - 避免在过程里用 8.0 新增保留字作变量名，如
rank、row_number、json
迁移后必须验证的三项运行时行为
光看 SHOW CREATE PROCEDURE 没用，必须实测执行路径。最容易被忽略的是错误处理机制和事务边界。
- 触发
SQLEXCEPTION时，5.7 的GET DIAGNOSTICS返回字段少，8.0 增加了RETURNED_SQLSTATE等，旧过程若依赖特定字段会取不到值 - 过程内含
START TRANSACTION但没配ROLLBACK分支，8.0 在异常退出时可能残留未提交事务，而 5.7 有时会自动回滚 - 调用含游标的存储过程，注意 8.0 对
FETCH后NOT FOUND的判断更严格，推荐统一用DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;方式
真正麻烦的不是语法转换，而是过程里那些没写进注释的隐式假设——比如“这个表一定有主键”“这个字段永远不为空”“GROUP BY 结果天然有序”。这些在 5.7 里侥幸成立，在 8.0 里就是定时炸弹。
