用 GROUP BY + 聚合函数做基础统计报表
绝大多数日报、月报、销售汇总，本质就是按维度分组后算总数、平均值、最大值等。MySQL 里最直接的方式就是
GROUP BY配合
COUNT()、
SUM()、
AVG()、
MAX()这类聚合函数。
常见错误是忘记写
GROUP BY却用了聚合函数，MySQL 5.7+ 默认会报错：
Expression #1 of SELECT list is not in GROUP BY clause—— 这不是 bug，是 SQL 标准严格模式在起作用。 想按部门统计员工数：用
SELECT dept, COUNT(*) FROM emp GROUP BY dept要算每个产品的月销售额：必须确保时间字段已转成年月（比如
DATE_FORMAT(order_time, '%Y-%m')），再和
product_id一起放进
GROUP BY聚合时过滤行要用
HAVING，不是
WHERE；
WHERE是分组前筛，
HAVING是分组后筛（例如只看销售额超 10 万的品类：
HAVING SUM(amount) > 100000）
处理日期维度：按日/周/月/年分组不能只靠 NOW()
报表常要“近 7 天”、“上个月”、“本季度”这类动态时间范围。硬写死日期（如
WHERE order_time >= '2024-05-01'）会导致每次跑脚本都要改 SQL，不可维护。
更可靠的做法是用 MySQL 内置日期函数动态计算边界：
上个月：用DATE_SUB(LAST_DAY(NOW()), INTERVAL 1 MONTH) + INTERVAL 1 DAY得到月初，再配合
LAST_DAY()得月末 近 7 天（含今天）：用
WHERE order_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY)按自然周分组（周一为起点）：用
YEARWEEK(order_time, 1)，注意第二个参数
1表示周一是每周第一天，否则默认是周日
别用
STR_TO_DATE()或字符串拼接来构造日期条件——性能差，还容易因时区或格式错漏导致漏数据。
多表关联统计时，COUNT(*) 和 COUNT(字段) 结果可能差很多
报表经常要连订单表、用户表、商品表。这时一个经典陷阱是：用
LEFT JOIN后直接
COUNT(*)，结果比实际订单数翻倍甚至更多——因为一个订单可能对应多个商品行（一对多），
JOIN后产生笛卡尔积。
正确做法取决于你要统计什么：
统计“有订单的用户数”：用COUNT(DISTINCT user_id)统计“订单总金额”，但订单表已是一行一单：用
SUM(order_amount)，别用
COUNT()统计“每个用户买了几个品类”，而商品表里一个订单有多条记录：得先子查询去重，或用
COUNT(DISTINCT category_id)
永远检查执行计划（
EXPLAIN）里
rows是否异常放大，那是关联膨胀的信号。
导出报表时避免内存溢出和连接超时
当统计涉及千万级订单、跨年数据、或要
GROUP BY多个高基数字段（如用户 ID + 商品 ID）时，MySQL 可能报错：
Lost connection to MySQL server during query或
Out of memory。
这不是代码写错了，而是服务端资源限制。关键调整点有三个：
增大临时表内存：SET SESSION sort_buffer_size = 8388608;（8MB），但别设太高，否则并发多时会挤爆物理内存 强制走索引：在
GROUP BY字段上建联合索引，顺序要匹配查询中
GROUP BY和
WHERE的字段顺序 拆分大查询：比如按月份循环查，再用应用层合并；或者加
LIMIT分页（注意
OFFSET深度大时也慢）
真正难的不是写出能跑的 SQL，而是预判它在生产数据量下会不会崩——上线前务必在接近真实规模的测试库上压测。
