SQL 数据统计与汇总 SQL 实战

1次阅读

mysql 5.7启用only_full_group_by后,select中非聚合字段必须在group by中出现或用聚合函数处理;count(*)统计所有行(含NULL),count(列名)仅统计该列非null值;日期范围建议用左闭右开避免丢失时间精度。

SQL 数据统计与汇总 SQL 实战

GROUP BY 后字段必须出现在 SELECT 或聚合函数里

MySQL 5.7 默认开启 ONLY_FULL_GROUP_BY 模式,直接写 SELECT user_id, name FROM orders GROUP BY user_id 会报错:Expression #2 of SELECT list is not in GROUP BY clause。这不是语法写错了,是 SQL 标准在强制你明确“每个分组里 name 取哪个值”。

常见错误是以为加个 ANY_VALUE(name) 就万事大吉——它确实能绕过报错,但结果不可预测,尤其当 name 在同一 user_id 下有多个值时,ANY_VALUE 随机返回一个,线上统计可能忽高忽低。

  • 真要取某个确定值:用 MAX(name)MIN(name)(前提是 name 是字符串且你接受字典序逻辑)
  • 要取最新一条的 name:先用子查询或窗口函数标记顺序,再关联取值,别硬套 ANY_VALUE
  • 确认是否真需要非分组字段:很多场景其实只需要 SELECT user_id, COUNT(*),多选字段反而暴露数据不一致风险

COUNT(*)、COUNT(1)、COUNT(列名) 行为完全不同

COUNT(*) 统计行数,包括 NULL;COUNT(1)COUNT(*) 在绝大多数引擎里执行计划一致,性能没差别;但 COUNT(列名) 只统计该列非 NULL 的行——这点常被忽略,导致漏统。

比如统计“下单用户数”,用 COUNT(user_id) 看似合理,但如果订单表里存在 user_id IS NULL 的测试单或匿名单,这部分就被排除了;而业务上往往要求“所有订单都算进总量”,此时必须用 COUNT(*)

  • 查去重数量?用 COUNT(DISTINCT user_id),别写成 COUNT(user_id) 再自己去重
  • 配合 WHERE 时注意 NULL:如果条件是 WHERE status = 'paid',那 COUNT(*)COUNT(status) 结果一样;但若 status 允许 NULL,且你想排除未设置状态的记录,就得显式写 WHERE status IS NOT NULL AND status = 'paid'

日期范围统计别只靠 BETWEEN

BETWEEN '2024-01-01' AND '2024-01-31' 看起来覆盖整月,但如果字段是 dateTIME 类型,它实际只查到 '2024-01-31 00:00:00',当天下午的订单就丢了。

更稳妥写法是用左闭右开区间:created_at >= '2024-01-01' AND created_at 。这样不管字段精度是秒还是毫秒,逻辑都清晰,也方便索引生效。

  • DATE(created_at) = '2024-01-01' 最省事,但会导致全表扫描——DATE() 函数让索引失效
  • 跨时区要注意:数据库时区、连接时区、应用层传入时间三者不一致时,'2024-01-01' 可能对应不同物理时刻,建议统一转成 UTC 存储和查询

JOIN 后 COUNT 容易重复计数

想统计每个用户的订单数和最近一次订单时间,写 SELECT u.id, COUNT(o.id), MAX(o.created_at) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id ——看着没问题,但如果一个用户有 5 条订单,又关联了 3 条地址记录,COUNT(o.id) 就会变成 15。

根本原因是 JOIN 扩展了行数,GROUP BY 前已经产生笛卡尔积。不是加个 DISTINCT 就能解决(COUNT(DISTINCT o.id) 可以,但性能差,且不能用于其他聚合如 SUM)。

  • 优先用子查询:先聚合订单表得到 user_id → order_count, last_order_time,再和 users 表 JOIN
  • 用窗口函数(MySQL 8.0+):在 orders 表里按 user_id 分组生成序号,再外层筛选 row_num = 1 的记录
  • LEFT JOIN 多张表时,务必检查每张表的关联基数,一张一对多,后面再接一对多,爆炸式增长就来了

复杂统计最麻烦的从来不是写法,而是搞清“这一行到底代表什么业务含义”。JOIN + GROUP BY 套两层以后,得拿几条真实数据手算一遍,否则上线才发现总数翻倍,没人信你只是少写了括号。

text=ZqhQzanResources