MySQL 5.7 存储过程导出后需清理语法、检查参数、重写逻辑才能导入 8.0，否则 CREATE PROCEDURE 阶段报错或运行异常；须排除系统库对象、替换不兼容 sql_mode、补全 SELECT INTO、修正错误处理、拆分 GRANT 语句、包裹保留字，并验证权限与字符集。
不能直接导入，必须先清理语法、检查参数、重写部分逻辑。 MySQL 5.7 的存储过程导出后，若不加处理直接导入 8.0，大概率在 CREATE PROCEDURE 阶段就报错，或运行时行为异常（比如参数绑定失效、错误处理跳过、SELECT 无 INTO 报错）。
导出时避免带系统库和不兼容模式
5.7 的 mysqldump --routines 默认会把 mysql 系统库里的存储过程也拉进来（比如 sys 库里的过程），而这些过程在 8.0 中结构已变，导入即失败。同时，导出文件开头的 SET sql_mode = 'NO_AUTO_CREATE_USER,...' 在 8.0 中非法，会导致整个 SQL 文件执行中断。
- 只导出业务库的 routine：
mysqldump -u root -p --no-create-info --no-data --routines --triggers --skip-extended-insert myapp_db > routines.sql - 手动删掉 SQL 文件头部所有
SET sql_mode行；若需保留严格模式，替换为 8.0 兼容值，例如：SET sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'; - 确认导出内容不含
mysql或sys库对象——搜索CREATE PROCEDURE `mysql.或CREATE PROCEDURE `sys.，有则删除整段
检查并重写不兼容语法
MySQL 8.0 对存储过程语法更严格，尤其在变量作用域、错误处理和返回逻辑上。常见报错包括 ERROR 1337 (42000)（变量未声明）、ERROR 1418 (HY000)（未显式指定 DETERMINISTIC 或 READS SQL DATA）、ERROR 1064（SELECT ... INTO 缺失目标变量）。
- 所有
SELECT必须配INTO（除非明确用于游标或结果集返回），否则报错；5.7 中允许裸SELECT，8.0 不再容忍 - 检查
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION块：若 handler 内部又调用含异常的语句，可能形成无限递归；建议改用GET DIAGNOSTICS显式捕获错误码 - 移除
NO_AUTO_CREATE_USER相关逻辑（该模式已在 8.0 移除），如过程里有GRANT ... IDENTIFIED BY语句，需拆成CREATE USER+GRANT两步 - 若过程名或参数名撞上 8.0 保留字（如
rank、json、group），必须用反引号包裹，例如：DECLARE `rank` INT DEFAULT 0;
导入前验证权限与字符集
8.0 默认认证插件是 caching_sha2_password，而很多老存储过程里硬编码了连接字符串或调用 mysql_real_connect()，若客户端驱动版本低（如 JDBC 5.x、PHP mysqlnd
- 导入前，在 8.0 实例中临时创建兼容用户：
CREATE USER 'migrator'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; GRANT ALL ON myapp_db.* TO 'migrator'@'%'; - 确保过程体内的字符串字面量与数据库默认字符集一致：5.7 可能用
utf8（实为utf8mb3），8.0 默认utf8mb4；导出时加--default-character-set=utf8mb4，导入前检查 SQL 文件中是否有CHARACTER SET utf8，替换为CHARACTER SET utf8mb4 - 导入命令必须指定用户和字符集：
mysql -u migrator -p --default-character-set=utf8mb4 myapp_db
导入后必须测试执行路径与错误分支
即使 CREATE PROCEDURE 成功，也不代表它能正常跑通。8.0 的优化器对子查询、窗口函数嵌套、临时表引用的行为有变化，某些在 5.7 中“侥幸通过”的逻辑，在 8.0 中可能因执行计划变更而卡死或返回空结果。
- 逐个调用过程，重点覆盖：空输入、边界值、触发异常的路径（如除零、主键冲突）、多事务嵌套场景
- 检查
information_schema.ROUTINES中的SQL_DATA_ACCESS字段是否为MODIFIES SQL DATA或READS SQL DATA，若为CONTAINS SQL（5.7 常见默认值），8.0 可能拒绝执行写操作 - 留意日志：
SHOW WARNINGS;和错误日志中是否有Warning Code 1287（弃用语法提示）或Warning Code 3613（不可见索引相关），它们常是后续失败的伏笔
真正麻烦的不是语法转换，而是那些没报错但逻辑偏移的地方——比如 5.7 中 GROUP BY 隐式排序被移除后，依赖该顺序的过程会返回乱序结果；又比如 JSON_EXTRACT 在 8.0 中对空路径返回 NULL 而非空字符串，导致判断逻辑失效。这些必须靠真实数据+业务用例验证，没法靠工具扫出来。
