MySQL 8.0升级避坑指南：从语法墙到连接失败，这些“坑”你踩过吗？
从MySQL 5.6或5.7升级到8.0，性能和安全提升是肉眼可见的，但过程往往没那么丝滑。冷不丁冒出的语法错误、连接失败，足以让运维同学心头一紧。别慌，这些多半是版本兼容性在“刷存在感”。下面这几个高频问题，几乎每个升级项目都会遇到，咱们逐一拆解。
MySQL 8.0 用 GROUP BY 报错：Expression #1 of SELECT list is not in GROUP BY clause
这大概是升级后撞上的第一堵“语法墙”。问题根源在于，MySQL 8.0默认启用了sql_mode=ONLY_FULL_GROUP_BY。这个模式其实是个“语法警察”，它要求SELECT列表里的每一个非聚合字段，都必须老老实实地出现在GROUP BY子句里。
错误提示很直接：ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause...。看到这个，先别急着去关掉ONLY_FULL_GROUP_BY——它报错，往往是在提醒你，SQL本身的逻辑可能有点模糊。比如，你选了name字段，却没明确告诉数据库，到底要按哪个name来分组聚合。
- 第一步，检查业务意图：这条SQL到底想干嘛？是想取分组后的任意一条记录，还是不小心漏写了
GROUP BY字段？ - 临时过渡方案：如果确认只是临时兼容需求，可以在当前会话中关闭它：
SET SESSION sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));。注意，这只对当前连接生效。 - 生产环境推荐做法：全局禁用
ONLY_FULL_GROUP_BY不是好主意。更稳妥的方式是重写SQL，使用ANY_VALUE(name)函数来显式声明：“我知道这个字段不在分组里，我只要它的任意一个值。”这样既满足了语法检查，也明确了开发者的意图。
MySQL 5.6 不支持 JSON_EXTRACT 或 -> 操作符
想用一句优雅的SELECT data->'$.user.id' FROM logs来提取JSON数据，却换来一个冰冷的FUNCTION JSON_EXTRACT does not exist？别怀疑自己，是数据库版本“拖了后腿”。JSON相关函数和操作符，是MySQL 5.7才引入的“现代武器”。
在处理日志、配置项或用户埋点这类半结构化数据时，JSON字段能省去大量应用层解析的麻烦。但在5.6及更早的版本里，这条路走不通。
- 5.6时代的“土法炼钢”：只能用
SUBSTRING_INDEX配合正则表达式（REGEXP）去硬解析TEXT字段，效率低且容易出错。 - 5.7+的正确姿势：直接使用
data->'$.user.id'提取JSON字面量，或者用data->>'$.user.id'（注意是两个>）直接返回去掉引号的字符串，用起来更顺手。 - 一个重要提醒：即使版本支持，也要确保字段类型是
JSON，而不是TEXT。如果存成TEXT，函数虽然能跑，但会失去JSON格式校验和专用的索引优化能力，性能大打折扣。
CREATE TABLE ... ENGINE=InnoDB ROW_FORMAT=COMPRESSED 在 MySQL 5.7 报错
从网上复制一段建表语句，执行时却提示ERROR 1031 (HY000): Table storage engine for 't' doesn't ha ve this option。十有八九，是ROW_FORMAT=COMPRESSED这个参数在当前的引擎或版本里“水土不服”了。
这个参数背后的兼容性问题，跟版本配置强相关：
- 依赖条件：使用
COMPRESSED行格式，需要innodb_file_per_table=ON，并且innodb_file_format需要是Barracuda。不过，innodb_file_format这个参数在MySQL 5.7.7之后就被废弃了，默认就支持。 - 版本差异：在MySQL 5.6中，你必须显式设置
innodb_file_format=Barracuda才能启用压缩表。而到了MySQL 8.0，innodb_file_format配置项直接被移除了，COMPRESSED格式虽然还能用，但压缩表无法使用ALGORITHM=INPLACE进行在线DDL操作，这在需要频繁改表的结构时会是个麻烦。 - 简单替代方案：对于大多数场景，其实可以直接删掉
ROW_FORMAT=COMPRESSED，使用默认的DYNAMIC行格式。压缩表带来的空间节省往往有限，却增加了运维的复杂度，性价比需要仔细权衡。
用 mysql -u root -p 连不上，提示 Access denied for user 'root'@'localhost'（但密码没错）
这看起来不是语法错误，却是升级后最高频的“卡脖子”问题。密码明明没错，怎么就拒绝访问了？症结在于认证插件。MySQL 8.0将默认的认证插件从大家熟悉的mysql_native_password，改成了更安全的caching_sha2_password。一些老的客户端（比如某些旧版本的Python MySQL驱动、老版Na vicat）还没来得及支持这个新插件。
怎么确认？执行这条SQL看看：SELECT user, host, plugin FROM mysql.user WHERE user='root';
- 如果
plugin显示caching_sha2_password，而你的老客户端连不上，最直接的解决办法就是把认证方式改回去：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';。 - 客户端兼容性是关键：不是所有应用都能方便地升级客户端库，尤其是一些遗留系统或嵌入式设备。
- 重要警告：千万不要图省事，直接用
UPDATE语句去修改mysql.user表里的plugin字段。这样会导致密码哈希失效，正确的姿势永远是使用ALTER USER命令来重置。
说到底，数据库版本升级，从来不是一次简单的“替换重启”。它更像是一次细致的体检，需要你盯着每一条遗留的SQL、每一个外部的连接、每一个建表参数，确认它们在新的环境里依然能“认得路，干得了活”。提前摸清这些常见的“坑”，升级之路才能走得更稳当。
