MySQL 升级后 SQL 报错，大概率是新版本加强了 SQL 标准合规性或移除了旧版兼容逻辑。重点排查 SQL 模式（sql_mode）变更、废弃语法、隐式类型转换限制、GROUP BY 严格化、窗口函数支持变化 这几类问题。
检查并调整 sql_mode 设置
MySQL 5.7 默认启用了
STRICT_TRANS_TABLES和
ONLY_FULL_GROUP_BY，8.0 进一步收紧。旧 SQL 若含非确定性 GROUP BY、插入截断字段、空字符串转数字等操作，会直接报错。 执行
SELECT @@sql_mode;查看当前模式 对比升级前后差异，重点关注
ONLY_FULL_GROUP_BY、
STRICT_TRANS_TABLES、
NO_ZERO_DATE、
ERROR_FOR_DIVISION_BY_ZERO临时调试可降低严格性（不推荐长期使用）：
SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';生产环境应修复 SQL，而非关闭严格模式
识别并替换已废弃或受限语法
MySQL 8.0 移除了部分兼容性语法，且对模糊写法更敏感：
CREATE TEMPORARY TABLE ... SELECT中若 SELECT 含子查询别名冲突，可能报错；建议显式写出列名 不再支持
mysql_old_password加密方式，但此影响连接，非 SQL 执行
ORDER BY中引用
SELECT列别名时，若别名含函数或表达式，在某些场景下需加括号或改用位置序号（如
ORDER BY 1） 删除了
CREATE TABLE ... SELECT中对目标表字段类型的隐式推导容错，必须确保 SELECT 字段与建表定义兼容
重写 GROUP BY 和聚合查询
启用
ONLY_FULL_GROUP_BY后，以下写法会失败：
SELECT id, name, COUNT(*) FROM user GROUP BY id;——
name未在 GROUP BY 中也未被聚合函数包裹 修复方式：补全 GROUP BY 字段，或用 ANY_VALUE(name) 包裹非分组字段（MySQL 5.7+ 支持） 或改写为确定性逻辑：
SELECT id, MAX(name), COUNT(*) FROM user GROUP BY id;检查视图、存储过程、触发器中的 GROUP BY，它们同样受约束
验证函数与关键字是否变更
MySQL 8.0 新增大量窗口函数（如 ROW_NUMBER()），但也调整了部分函数行为：
JSON_EXTRACT()返回值类型更严格，旧代码若依赖自动转字符串，可能需显式加
CAST(... AS CHAR)
GROUP_CONCAT()默认最大长度从 1024 调整为 1024（不变），但超长截断不再警告，需检查结果完整性 新增保留字如
ROLE、
CACHE、
COMPONENT，若用作列名/表名，必须用反引号包裹 执行
SELECT keyword FROM information_schema.KEYWORDS WHERE reserved = 'YES' AND db_major_version = '8.0';可查新增保留字
升级前做兼容性扫描更高效：可用 MySQL Shell 的 util.checkForServerUpgrade() 工具预检 SQL 风险点。线上变更务必在测试库完整回放业务 SQL 流量。
