在写统计类SQL时，不少人遇到过这样的怪事：已经用GROUP BY对某个业务字段做了分组，执行后却看到多行“看起来一样”的数据。这种现象通常不是数据库分组逻辑出错，而是SELECT列表里混入了没有参与分组、也没有被聚合的隐藏列，导致分组维度被悄悄放大。
一、隐藏列是如何破坏分组的
标准SQL规定，当使用GROUP BY时，SELECT后面出现的每一个列，必须满足两个条件之一：要么是GROUP BY子句里的分组列，要么被聚合函数（如COUNT、SUM、MAX）包裹。如果SELECT里多出了一个不在GROUP BY中、也没被聚合的列，数据库就会把这个列也当作分组依据的一部分。
所谓“隐藏列”，往往是开发者容易忽略的字段。例如订单表里的自增主键order_id、记录更新时间的update_time，或者从多表JOIN中顺手选出的外部表主键。它们在业务上不影响统计口径，但每一行的值都不同。一旦被选出来，原本按user_id分组的查询，实际上变成了按user_id + order_id分组，自然就会产生大量“重复”行。
1.1 一个典型的错误写法
下面这段SQL想统计每个用户的下单总数，却把订单主键也查了出来：
SELECT
user_id,
order_id,
COUNT(*) AS order_cnt
FROM orders
GROUP BY user_id;
在严格模式的数据库（如开启ONLY_FULL_GROUP_BY的MySQL）中会直接报错；但在非严格模式或部分其他数据库中，order_id会被隐式纳入分组，导致每个订单占一行，order_cnt永远等于1，完全背离了统计初衷。
1.2 为什么叫“隐藏”
这些列之所以隐蔽，是因为它们经常通过星号或ORM框架自动生成。比如使用SELECT * 时，表里默默躺着的主键、时间戳就会被带出。又比如MyBatis里写了resultType为实体类，自动映射了所有字段，其中就包含无关列。
二、如何系统性排查SELECT中的多余列
解决这类问题不需要靠猜，可以按固定步骤检查。第一步，把实际执行的SQL中的SELECT部分单独列出，逐个字段追问：这个字段在GROUP BY里吗？如果不在，它有聚合函数吗？
第二步，如果使用的是SELECT *，请改成显式字段列表。第三步，对JOIN场景，确认从被关联表中取出的字段是否真的需要出现在最终结果，不需要的就移出SELECT。下面给出一个修正后的正确写法：
SELECT
user_id,
COUNT(*) AS order_cnt,
MAX(order_time) AS last_order_time
FROM orders
GROUP BY user_id;
这里order_time通过MAX聚合，既保留了“最近下单时间”的信息，又不破坏按user_id分组的逻辑。如果确实要展示某个订单的明细，那说明需求本身就不是纯分组统计，应该拆成子查询或窗口函数来处理。
2.1 利用执行计划辅助确认
在MySQL中可以用EXPLAIN查看GROUP BY是否使用了临时表和文件排序，并结合输出来判断分组字段。虽然EXPLAIN不会直接列出隐藏列，但当你发现预期应返回10行的查询返回了1000行，基本就能反推SELECT带了多余维度。
| 排查动作 | 目的 |
|---|---|
| 展开SELECT字段清单 | 找出未聚合且不在GROUP BY中的列 |
| 禁用SELECT * | 避免无意带入主键等隐藏列 |
| 检查ORM映射 | 防止框架自动选出全部表字段 |
三、窗口函数场景下的另一种“重复”
有些开发者用窗口函数做分组排序，例如ROW_NUMBER() OVER(PARTITION BY user_id)，随后在外部查询里既保留了分区列又保留了排序后的行，也会造成相似观感。此时并不是GROUP BY失效，而是没有在外层再做一次聚合或过滤。
如果业务只要每用户的最新订单，应当用子查询先取号，再筛序号为1的行，而不是把窗口函数结果和原始多行直接SELECT出来。理解隐藏列的本质，是分清“分组统计”和“分组内明细”两条不同的查询路线。
3.1 代码示例：先编号再过滤
SELECT user_id, order_id, order_time
FROM (
SELECT
user_id,
order_id,
order_time,
ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY order_time DESC) AS rn
FROM orders
) t
WHERE t.rn = 1;
这种写法明确区分了分组内层与输出层，不会出现因SELECT隐藏列而导致的假重复。掌握上述思路后，再遇到GROUP BY后仍有重复行，就能快速定位到SELECT里的“漏网之鱼”。