GROUP BY配合聚合函数是统计报表核心，需注意分组语法、动态日期计算、关联膨胀规避及性能优化。
用 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 后产生笛卡尔积。
使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能
正确做法取决于你要统计什么：
- 统计“有订单的用户数”：用
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，而是预判它在生产数据量下会不会崩——上线前务必在接近真实规模的测试库上压测。
