MySQL 5.7+ 默认启用 ONLY_FULL_GROUP_BY 模式，要求 ORDER BY 字段必须出现在 SELECT 或 GROUP BY 中，否则排序无效；解决方式包括使用聚合函数（如 MAX）、ANY_VALUE() 或窗口函数（如 ROW_NUMBER()）显式确定每组排序依据。
MySQL 5.7+ 默认 SQL 模式导致 ORDER BY 字段必须出现在 SELECT 或 GROUP BY 中
MySQL 5.7 开始默认启用 ONLY_FULL_GROUP_BY 模式，它强制要求 ORDER BY 中的字段要么在 SELECT 列表中，要么是 GROUP BY 的一部分，否则排序会被忽略（即使语句能执行，结果顺序也不受控）。这不是 bug，而是 SQL 标准合规性增强——MySQL 不再容忍“隐式依赖非分组列”的歧义行为。
- 现象：写
SELECT name FROM users GROUP BY dept_id ORDER BY created_at DESC，结果顺序随机，created_at完全不生效 - 原因：
created_at既没出现在SELECT，也没在GROUP BY，MySQL 认为该字段对每个分组不唯一，无法确定“按哪个值排序” - 验证方式：执行
SELECT @@sql_mode，若返回包含ONLY_FULL_GROUP_BY，即处于严格模式
想按某字段排序，就得让该字段在分组逻辑中可确定
不能靠“碰运气选一条”，得显式告诉 MySQL 每组用哪条记录的字段值来排序。常见做法是用聚合函数包裹排序字段，或先子查询再排序。
- 用
MAX()/MIN()：如SELECT dept_id, MAX(created_at) AS latest_time FROM users GROUP BY dept_id ORDER BY latest_time DESC—— 这里排序的是每组最大时间，合法且明确 - 用
ANY_VALUE()（MySQL 5.7+）：如SELECT dept_id, ANY_VALUE(name), MAX(created_at) FROM users GROUP BY dept_id ORDER BY MAX(created_at) DESC，但注意ANY_VALUE(name)不保证是最新那条的name - 更安全的做法是先按目标字段排序，再分组（依赖 MySQL 8.0+ 窗口函数或子查询）：例如用
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY created_at DESC)标记每组最新记录，再过滤出序号为 1 的行
关闭 ONLY_FULL_GROUP_BY 是权宜之计，不是解决方案
临时禁用可以绕过报错，但会让排序行为退化为不可预测的引擎实现细节（比如 InnoDB 可能按主键物理顺序返回，MyISAM 可能按插入顺序），不同版本、不同负载下结果都可能变化。
- 不推荐：执行
SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''))—— 仅当前会话生效，且掩盖了逻辑缺陷 - 更危险的是全局修改配置文件
my.cnf中的sql_mode，会导致所有应用失去分组一致性保障 - 真正的问题不在 SQL 能不能跑，而在于“你是否清楚每组最终展示的那条记录，其非分组字段的值到底来自哪一行”
MySQL 8.0+ 的窗口函数提供更清晰的替代路径
如果目标是“取每组最新的一条完整记录”，直接用 ROW_NUMBER() 比嵌套子查询 + GROUP BY 更直观、更可控。
- 示例：
SELECT id, name, dept_id, created_at FROM ( SELECT id, name, dept_id, created_at, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY created_at DESC) AS rn FROM users ) t WHERE rn = 1; - 优势：无需担心
GROUP BY和ORDER BY的字段冲突，语义明确，“每组按时间倒序排，取第一行” - 注意：窗口函数在
GROUP BY之后执行，所以它天然规避了传统分组排序的字段可见性问题
真正容易被忽略的点是：GROUP BY 的本质是降维聚合，而 ORDER BY 是对结果集的线性排列。当两者共存时，MySQL 要求排序依据必须是“已确定的维度值”，而不是“未聚合的原始行字段”。别把排序当成“选一条”，得先定义清楚“这条怎么算出来”。
