GROUP BY后SELECT字段必须在分组键中或套聚合函数，否则MySQL 5.7+严格模式下报错；取每组最新完整记录应优先用窗口函数ROW_NUMBER()，而非硬套GROUP BY或依赖时间字段JOIN。
GROUP BY 后 SELECT 的字段必须在分组键里或套聚合函数
这是最常触发 SQLSTATE[42000]: Syntax error or access violation 的原因。MySQL 5.7+ 和严格模式下，SELECT a, b, COUNT(*) FROM t GROUP BY a 会直接报错，因为 b 既没出现在 GROUP BY 里，也没被 MAX()、MIN() 等包裹。
实际场景比如：查每个用户最新一条订单，你写了子查询 (SELECT * FROM orders WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1)，但外层又想按用户分组取多个字段——这时不能靠子查询“绕开”GROUP BY规则。
- 正确做法是把所有非分组字段用聚合函数包住，例如
MAX(order_no)、MAX(status) - 如果真要取“最新那条的完整记录”，得用窗口函数（如
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)）或关联子查询 + 主键比较，而不是硬套 GROUP BY - 别依赖 MySQL 5.6 以前的“宽松模式”，上线后换环境就崩
嵌套子查询里用 GROUP BY 导致外层结果重复？检查是否漏了去重逻辑
典型现象：外层查出 10 行，但预期只有 5 行；打开子查询单独执行，发现它本身就有重复 user_id —— 说明子查询内部 GROUP BY 没收敛到唯一键，外层 JOIN 或 IN 又把它炸开了。
比如写成：SELECT * FROM users u WHERE u.id IN (SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) > 3)，看起来没问题，但如果 orders 表有脏数据（同一 user_id 出现在多行但没被真正聚合），或者 GROUP BY 字段选错了（比如用了 GROUP BY user_id, status 却只拿 user_id），就会让子查询返回多个相同 user_id。
- 子查询结尾加
DISTINCT是临时解法，但掩盖了分组逻辑问题 - 优先确认子查询的
GROUP BY字段是否和你要关联的外键完全一致 - 用
EXPLAIN看子查询是否走了索引；没走的话，GROUP BY 效率低，还容易因临时表大小限制截断结果
用 GROUP BY 归纳后再查原表，别直接 SELECT *
有人习惯先 SELECT user_id, MAX(created_at) AS last_time FROM orders GROUP BY user_id，再拿这个结果去 JOIN orders 表查完整记录。但如果直接 SELECT * FROM orders o JOIN (...) t ON o.user_id = t.user_id AND o.created_at = t.last_time，会漏掉 created_at 相同的多条记录（比如同一秒下了两单），也可能误取到其他用户的同时间记录（没加主键/唯一约束时）。
- JOIN 条件里必须包含能唯一确定一行的字段，比如
o.id = (SELECT id FROM orders o2 WHERE o2.user_id = t.user_id ORDER BY created_at DESC, id DESC LIMIT 1) - 更稳的方式是用窗口函数：给每组标序号，再筛
rn = 1，避免时间精度导致的歧义 - 别在 GROUP BY 子查询里用
SELECT *，MySQL 不允许，PostgreSQL 会报错，SQLite 行为不一致
GROUP BY 性能卡在临时表或文件排序？看字段类型和索引
当嵌套子查询里 GROUP BY 耗时飙升，90% 是因为没索引或字段类型不匹配。比如 GROUP BY SUBSTRING(phone, 1, 3)，哪怕 phone 有索引，函数计算也用不上；又比如 GROUP BY status，但 status 是 TEXT 类型，MySQL 会强制建临时表并排序。
- 确保 GROUP BY 字段是整型或短字符串，且独立成索引列（不要只是联合索引的第二列）
- 避免在 GROUP BY 中用函数、表达式、类型转换，如
CAST(x AS CHAR)、DATE(created_at) - 如果必须按日期分组，先把
DATE(created_at)存成新字段并建索引，比每次计算快得多
GROUP BY 的坑不在语法多难，而在它表面简单，实则对数据分布、索引结构、SQL 模式都敏感。一个没注意的字段类型，就能让子查询从毫秒变秒级，还查不出错——它只是慢，然后超时。
