mysql workbench迁移助手不校验sql语法兼容性，仅负责结构与数据迁移；验证需用prepare/deallocate手动解析、sql_mode切换、权限检查及explain对比等组合手段。
MySQL Workbench 迁移助手本身不校验 SQL 语法兼容性，它只负责结构和数据迁移；真要验证升级前的 SQL 兼容性，得绕开它，用更底层、更可控的方式。
为什么不能依赖迁移助手做兼容性验证
迁移助手（Migration Wizard）在 MySQL Workbench 中的核心任务是：解析源库元数据 → 生成目标库 DDL → 执行数据抽取/加载。它默认跳过 SQL 语句级的语法校验，也不会报出 ONLY_FULL_GROUP_BY 导致的 ERROR 1055，更不会提醒你 PASSWORD() 函数已在 8.0 被移除。它甚至可能静默改写某些语句（比如把旧式 JOIN 转成 ANSI JOIN），掩盖真实兼容性风险。
常见错误现象包括：
- 迁移后应用报
Unknown column 'xxx' in 'field list'，实则是视图定义里用了被弃用的别名推导规则 - 存储过程执行失败但迁移日志显示“成功”，因为迁移助手只检查 CREATE PROCEDURE 语法，不执行
CALL - 慢查询突然变快或变慢——优化器行为变了，但迁移助手完全不提示
用 PREPARE + DEALLOCATE 验证单条语句是否可解析
这是最轻量、最可靠的手动验证方式，不改动数据，只让 MySQL 服务端做词法和语法分析。适用于检查慢查询日志里的高频语句、应用代码中拼接的动态 SQL。
操作步骤：
- 连接到目标版本的测试实例（如升级后的 8.0.34）
- 对每条待验证 SQL 执行：
PREPARE stmt FROM 'SELECT id, name FROM users WHERE created_at > ?';<br>DEALLOCATE PREPARE stmt;
- 若语句含语法错误（如漏括号、错关键字），MySQL 立即抛出
ERROR 1064；若通过，说明该语句至少能被当前版本解析 - 注意：参数占位符
?必须保留，避免因字面值触发隐式类型转换报错，干扰语法判断
批量验证时用 mysql -e 自动化执行
把要测的 SQL 按行存为 queries.sql，每行一条（不含分号），然后用 shell 脚本逐条喂给 mysql 客户端：
while IFS= read -r sql; do<br> if [ -n "$sql" ]; then<br> echo "Testing: $sql"<br> if ! mysql -u testuser -ptestpass -h127.0.0.1 -P3307 -e "PREPARE s FROM '$sql'; DEALLOCATE PREPARE s;" 2>/dev/null; then<br> echo "❌ FAILED: $sql"<br> fi<br> fi<br>done <p>关键点：</p>
- 必须指定目标端口（如
-P3307）连接已部署好的新版本实例 -
2>/dev/null屏蔽正常输出，只捕获错误；失败时打印原语句便于定位 - 不要用
source queries.sql，它会把整个文件当一个语句解析，无法按行反馈 - 遇到含换行的复杂语句（如多行子查询），需先用工具预处理为单行
容易忽略的兼容性陷阱
很多问题不在语法层，而在运行时行为或默认配置变化：
-
sql_mode默认值不同：5.7 默认不含ONLY_FULL_GROUP_BY，8.0 含。即使PREPARE成功，执行时仍可能报错 - 字符集隐式转换：从
utf8mb3升级到utf8mb4后，索引长度超限导致CREATE INDEX失败，但PREPARE不报 - 权限模型变更：8.0 的
caching_sha2_password认证插件，老客户端连不上——这根本不是 SQL 语法问题，但属于“兼容性”范畴 - JSON 字段行为：8.0.29+ 对
JSON_EXTRACT返回值类型更严格，旧 SQL 可能因隐式转换失败
真正要覆盖全面，得把 PREPARE 验证、sql_mode 切换测试、权限连通性检查、以及关键路径的 EXPLAIN FORMAT=TREE 对比，全串成一个检查清单。别只盯着“能不能跑”，得问“跑出来的结果和原来一样吗”。
