MySQL 5.7存储过程直接导入8.0会失败，主因是8.0严格SQL模式、DEFINER校验增强及语法不兼容；需用mysqldump加--skip-definer和--compatible=mysql57导出，并导入时加--init-command="SET sql_mode='';"临时放宽限制。
MySQL 5.7 → 8.0 存储过程导入失败的典型报错
直接用 mysqldump --routines 导出再导入到 MySQL 8.0，大概率会遇到 ERROR 1064 (42000) 或 ERROR 1072 (42000)。根本原因不是语法写错，而是 MySQL 8.0 默认启用了更严格的 SQL 模式（如 STRICT_TRANS_TABLES），同时移除了部分旧版兼容行为——比如对 DEFINER 用户不存在时的静默降级、对无 SQL SECURITY 显式声明的默认处理逻辑。
导出时必须加 --skip-definer 和 --compatible=mysql57
不加这两个参数，mysqldump 会按当前服务端版本（8.0）生成含 DEFINER=`user`@`host` 的语句，而目标环境若无该用户或 host 不匹配，就会报错；且默认不降级语法，导致 CREATE PROCEDURE p() BEGIN ... END 中隐式使用的分号被解析器截断。
-
--skip-definer：去掉DEFINER子句，避免权限校验失败 -
--compatible=mysql57：强制将语法降级为 5.7 兼容格式（例如不生成SQL SECURITY DEFINER默认值） - 必须搭配
--default-character-set=utf8mb4，否则中文注释或参数名可能乱码
导入前需临时关闭 sql_mode 限制
即使导出合规，MySQL 8.0 启动时仍会校验存储过程体内的语法合法性。比如旧过程里有 SELECT * FROM t WHERE c = '' 配合 NOT NULL 字段，或使用了已被标记为废弃的 OLD_PASSWORD() 函数，都会在 CREATE PROCEDURE 执行时直接报错。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 导入命令中加
--init-command="SET sql_mode='';"，例如：mysql -u root -p --init-command="SET sql_mode='';" db_name - 或先连进去手动执行：
SET sql_mode='';，再source dump.sql - 注意：这仅绕过创建阶段校验，不解决运行时逻辑错误——比如调用已删除函数仍会在执行时报错
过程体内部逻辑要人工检查三类高危点
自动工具无法识别语义变化，以下三类写法在 5.7 可跑，8.0 极易崩溃：
- 使用
OLD_PASSWORD()、ENCRYPT()等已被移除的加密函数 → 替换为SHA2()或应用层处理 - 过程内直接操作
mysql系统库（如更新user表）→ 8.0 要求显式FLUSH PRIVILEGES，且权限模型变更，建议改用CREATE USER/GRANT - 依赖隐式类型转换的条件判断，如
IF col = '123'（col 是 INT）→ 8.0 在严格模式下可能触发类型不匹配警告甚至中断
真正麻烦的从来不是建过程，而是过程第一次被执行时才暴露的兼容性问题——别只验证 CREATE 成功，一定要在测试库上实际调用关键路径。
