SELECT中非聚合字段必须全部出现在GROUP BY中；日期需先提取年月再分组；WHERE用于分组前过滤，HAVING用于分组后筛选；建索引可提升性能。
GROUP BY 必须包含所有非聚合字段
直接写 SELECT SUM(sales), month FROM orders GROUP BY month 看似合理，但多数数据库（如 PostgreSQL、SQL Server）会报错：column "orders.month" must appear in the GROUP BY clause or be used in an aggregate function。MySQL 在严格模式下也会拒绝执行。
真正能跑通的写法是把所有非 SUM() 字段都放进 GROUP BY：
SELECT SUM(amount) AS total_sales, month, year FROM sales GROUP BY year, month;
注意顺序不重要，但字段必须一一对应 —— 如果 SELECT 里有 year 和 month，GROUP BY 就不能只写 month。
日期字段要先提取年月再分组
原始数据里如果只有 order_date（类型为 DATE 或 TIMESTAMP），不能直接 GROUP BY order_date，否则每天一条记录，根本不是“月度”。得先用函数归一化到年月粒度。
不同数据库语法不同，常见写法：
- MySQL / PostgreSQL：
GROUP BY EXTRACT(YEAR FROM order_date), EXTRACT(MONTH FROM order_date) - PostgreSQL 更简洁：
GROUP BY DATE_TRUNC('month', order_date) - SQL Server：
GROUP BY YEAR(order_date), MONTH(order_date) - SQLite：
GROUP BY strftime('%Y-%m', order_date)
推荐统一用字符串格式化（如 TO_CHAR(order_date, 'YYYY-MM') 或 DATE_FORMAT(order_date, '%Y-%m')），结果更直观，排序也符合时间顺序。
SUM() 遇到 NULL 默认忽略，但要注意 WHERE 过滤时机
SUM() 本身对 NULL 安全 —— 它自动跳过 NULL 值，不会让整行求和失效。但如果你加了 WHERE 条件，比如 WHERE status = 'completed'，就必须想清楚：这个过滤是在分组前还是后？
常见错误是漏掉有效订单状态：
- 没加
WHERE→ 把已取消、退款的订单也算进销售额 - 写了
WHERE amount > 0→ 可能漏掉金额为 0 的促销单（有些业务需要计入） - 用
HAVING SUM(amount) > 0过滤 → 这是分组后筛选，无法剔除某条NULL或负值记录对当月总和的影响
原则：业务规则决定的过滤（如只算已完成订单）一律放在 WHERE；只跟聚合结果有关的条件（如“只看月销超10万的月份”）才用 HAVING。
别忘了索引和性能陷阱
当表很大时，GROUP BY + SUM() 很容易变慢，尤其涉及日期函数转换（如 DATE_TRUNC()）时，数据库通常无法走索引。
提速关键点：
- 在原始日期字段（如
order_date）上建索引，比在表达式上建函数索引更通用 - 如果高频查月度汇总，考虑加一个生成列
sales_month CHAR(7) GENERATED ALWAYS AS (TO_CHAR(order_date, 'YYYY-MM')) STORED，再给它建索引 -
SUM(amount)如果涉及大量行，确认amount是数值类型（不是TEXT或带单位的字符串），否则会隐式转换失败或结果异常
实际跑之前，先用 EXPLAIN 看执行计划 —— 如果出现 Seq Scan 或 Temporary Table，基本说明没走索引或数据量超出内存缓冲区。
