group by后字段必须出现在select或聚合函数中，否则报错；where过滤行、having过滤分组，顺序不可逆；join统计需防count(*)因一对多被放大；日期范围宜用>=和
GROUP BY 后字段必须出现在 select 或聚合函数里
写统计 sql 时最常报错：Error: column "xxx" must appear in the GROUP BY clause or be used in an aggregate function。这不是 postgresql 特有，mysql 8.0+ 严格模式、SQL Server、oracle 都会拦。根本原因是 SQL 标准要求：SELECT 列要么是 GROUP BY 的列，要么被 count()、SUM() 这类函数包裹。
常见错误场景：想查每个部门的平均薪资，顺手加了个 employee_name —— 这就崩了，因为一个部门多人，数据库不知道该返回谁的名字。
- 正确做法：只选分组维度（如
dept_id）和聚合结果（如AVG(salary)） - 如果真要带某个人名（比如最新入职的），得用窗口函数或子查询，不能直接塞进
SELECT - MySQL 5.7 默认允许“非标准”写法，但上线后切到 8.0 或换数据库立刻报错，别依赖它
WHERE 和 HAVING 混用导致过滤失效
WHERE 过滤行，HAVING 过滤分组，顺序不可逆。写成 WHERE COUNT(*) > 10 必然报错，因为 COUNT(*) 在 WHERE 阶段还没算出来。
典型误用：想筛出订单数超 5 的用户，却把条件写在 WHERE 里；或者反过来，用 HAVING 去过滤单条记录的状态字段（比如 HAVING status = 'paid'），这会漏掉未达聚合阈值的组。
- 先用
WHERE卡原始数据（如WHERE order_date >= '2024-01-01'） - 再用
GROUP BY分组 - 最后用
HAVING筛分组结果（如HAVING COUNT(*) > 5） - 性能上，
WHERE越早过滤，扫描行数越少；HAVING是对内存中已分好的组操作，代价更高
JOIN 多表统计时 COUNT(*) 错误放大
一对多关联（比如订单表 JOIN 订单明细表）后直接 COUNT(*)，结果会变成明细行数，不是订单数。这是新手踩坑率最高的点之一。
例如：查每个用户的订单总数 + 订单总金额，若用 LEFT JOIN orders o ON u.id = o.user_id LEFT JOIN order_items i ON o.id = i.order_id，再 COUNT(o.id)，实际得到的是订单明细条数，不是订单张数。
- 解决办法一：用
COUNT(DISTINCT o.id)，但注意DISTINCT在大数据量下可能拖慢速度 - 解决办法二：先聚合明细表（如用子查询算出每个订单的金额总和），再和主表 JOIN，避免笛卡尔膨胀
- MySQL 8.0+ 可用 CTE 拆开步骤，逻辑更清晰，也方便加索引提示
日期范围统计用 BETWEEN 容易漏数据
写 WHERE create_time BETWEEN '2024-01-01' AND '2024-01-31'，看着没问题，但实际会漏掉 1 月 31 日 10:23:45 这类带时间的数据——因为 BETWEEN 默认闭区间，而字符串 `’2024-01-31’` 被隐式转成 '2024-01-31 00:00:00'。
业务上“查 1 月份数据”几乎都指从 1 日 00:00:00 到 31 日 23:59:59，硬写终点容易出错，也难维护。
- 推荐写法：
WHERE create_time >= '2024-01-01' AND create_time ，语义明确且能走索引 - PostgreSQL 支持
DATE类型直接比较，MySQL 建议用DATE(create_time) = '2024-01-01'仅限小数据量，否则无法用索引 - 如果字段是
timestamp WITH TIME ZONE，还得确认时区是否对齐，否则跨区统计会偏移
统计 SQL 最麻烦的从来不是语法，而是数据语义的理解偏差——比如“活跃用户”到底指登录过、下单过，还是支付成功过。字段含义、空值处理、时区、精度丢失，这些地方不抠清楚，再漂亮的 GROUP BY 也跑不出真实结果。