mysql 8.0报错“expression #n”表示select列表中第n个非聚合字段既未出现在group by子句，也未使用max()、any_value()等函数处理，因默认启用only_full_group_by模式而拒绝执行。
因为 MySQL 8.0 默认启用 ONLY_FULL_GROUP_BY 模式，而你原来的 SQL 中存在未聚合、也未出现在 GROUP BY 子句里的字段——这不是 bug，是标准校验变严了。
报错信息里“Expression #N”是什么意思？
这是 MySQL 在告诉你：SELECT 列表中第 N 个字段（从 1 开始数）违反了 ONLY_FULL_GROUP_BY 规则。比如错误提示 Expression #2 of SELECT list is not in GROUP BY clause，说明第二列（如 product_name）既没被 MAX() 包裹，也没加进 GROUP BY。
- 常见现象：5.7 能跑的
SELECT user_id, product, SUM(amount) FROM orders GROUP BY user_id，在 8.0 直接报错 - 根本原因不是字段名写错，而是语义不合法：MySQL 不再允许“随机选一行的
product值”这种不确定行为 - 注意
nonaggregated column这个关键词——它特指没套聚合函数的普通列，不是指数据类型或 NULL 问题
为什么加了主键进 GROUP BY 还报错？
MySQL 8.0 对“函数依赖”的判断更严格：即使你写了 GROUP BY id，如果表没显式定义主键约束，或者该列只是业务主键但未设 PRIMARY KEY，MySQL 就不认为 name 和 id 存在一对一关系，仍会拒绝执行。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 验证方式：
SHOW CREATE TABLE your_table看是否有PRIMARY KEY或UNIQUE NOT NULL约束 - 别依赖“我知道这是一对一”，MySQL 只认元数据定义，不猜业务逻辑
-
ANY_VALUE()能绕过检查，但它只是告诉 MySQL “我接受不确定性”，不会改变底层依赖判定
临时禁用 ONLY_FULL_GROUP_BY 的风险
用 SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')) 确实能立刻让老 SQL 跑通，但隐患藏得深：
- 同一段 SQL 在不同会话可能返回不同结果（比如
product随机取某行值），排查数据异常时极难复现 - ORM 或中间件可能缓存会话级
sql_mode，导致部分请求生效、部分不生效 - 升级后首次部署常忽略这点，等上线几天才发现报表数据对不上，回溯成本远高于改 SQL
哪些场景下 ANY_VALUE() 是合理选择？
它不是补丁，而是明确表达语义的工具——只适用于你**真的不关心取哪一行值**的场合：
- 日志类宽表做粗粒度统计，例如
SELECT app_id, ANY_VALUE(version), COUNT(*) FROM log GROUP BY app_id - ETL 中临时中间表，后续还会被 JOIN 或过滤，当前分组值仅作占位
- 注意：
ANY_VALUE(name)和MAX(name)性能差异不大，但语义完全不同；前者不保证字典序，后者会触发字符串比较开销
真正容易被忽略的点是：很多报错 SQL 其实隐含了数据建模缺陷——比如把“部门-负责人”这种本该是 1:1 关系的字段，硬塞进一对多的订单表里做聚合。这时候修 SQL 不如先理清实体关系。
