GROUP BY后出现重复行不是笛卡尔积，主因是分组键不唯一或SELECT混用非聚合字段；验证方法为对比COUNT(*)与COUNT(DISTINCT group_cols)，并启用ONLY_FULL_GROUP_BY模式。
GROUP BY 后出现重复行，是不是笛卡尔积？
不是。真正的笛卡尔积发生在 JOIN 时未加限制条件，而 GROUP BY 本身不会产生笛卡尔积。你看到的“冗余行”，大概率是分组键不唯一（比如多列组合中某列有重复值但其他列不同），或在 SELECT 中混用了非聚合字段和聚合函数，触发了 MySQL 5.7 以前的宽松模式（sql_mode 不含 ONLY_FULL_GROUP_BY），导致隐式随机取值——看起来像重复，实则是未定义行为。
验证方法：执行 SELECT COUNT(*) FROM (your_grouped_query) t 和 SELECT COUNT(DISTINCT group_col1, group_col2) FROM table 对比，若前者显著更大，说明 SELECT 列里混入了非分组、非聚合字段。
为什么不能在 GROUP BY 前用 DISTINCT 去重？
DISTINCT 作用于整行结果，而聚合计算依赖原始数据分布。提前去重会破坏统计意义——比如同一用户多次下单，去重后变成“1次”，再算 SUM(amount) 就完全失真。
常见误用场景：
- 想消除因关联表带来的重复计数，却对主表
DISTINCT后再聚合 → 应该用COUNT(DISTINCT user_id)而非DISTINCT * - 把
SELECT DISTINCT a, b, SUM(c) FROM t GROUP BY a, b当作合法写法 → 这在标准 SQL 中语法错误，MySQL 可能允许但结果不可靠
正确做法是：先明确业务语义——你要去重的是什么维度？用户？订单？时间粒度？然后用对应粒度的 DISTINCT 套在聚合函数内。
COUNT(DISTINCT ...) 是唯一安全的“预去重”方式吗？
是目前最常用且语义清晰的方式，但它只适用于计数类聚合。其他聚合如 SUM、AVG、MAX 无法直接套 DISTINCT（除 PostgreSQL 支持 SUM(DISTINCT x) 外，MySQL、SQL Server 等均不支持）。
替代方案取决于场景：
- 需要去重后求和 → 先用子查询或 CTE 按业务键去重（如每个
order_id只取最新一条），再对外层聚合 - 关联导致重复 → 改用
EXISTS或LATERAL（PostgreSQL/SQL Server 2022+）代替JOIN，避免膨胀 - MySQL 8.0+ 可用窗口函数：先
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts DESC)标记每组首行，再过滤rn = 1后聚合
注意：COUNT(DISTINCT x) 在大数据量下可能内存溢出（尤其 x 是字符串），可考虑加近似函数如 APPROX_COUNT_DISTINCT(x)（BigQuery / Spark SQL）或分桶采样。
GROUP BY + 聚合时，哪些字段能放进 SELECT？
只有两类安全：分组键本身，或明确用聚合函数包裹的字段。任何漏掉的非聚合字段都属于未定义行为，不同数据库表现不同：
- PostgreSQL / SQL Server / MySQL 8.0+（启用
ONLY_FULL_GROUP_BY）→ 直接报错ERROR 1055 - 旧版 MySQL → 随机返回某一行的值，极易引发线上统计偏差
检查方法：运行 SELECT @@sql_mode，确认包含 ONLY_FULL_GROUP_BY；开发阶段务必开启它。
容易被忽略的一点：即使所有字段都写了聚合函数，如果分组键逻辑上不唯一（例如用 DATE(created_at) 分组，但表里存在毫秒级时间差），仍可能因隐式类型转换或索引失效导致意外重复——建议显式用 CAST(created_at AS DATE) 并在该表达式上建函数索引。
