GROUP BY后直接用SUM()即可，但必须将SELECT中所有非聚合字段（如product_name、region、year）全部列入GROUP BY子句，否则严格模式下报错；WHERE过滤分组前的行，HAVING过滤分组后的结果；SUM()自动忽略NULL，全NULL时返回NULL，可用COALESCE(SUM(), 0)转为0。
GROUP BY 后直接用 SUM() 就行，但必须确保非聚合字段全在 GROUP BY 里
SQL 中计算分组销售总额，核心就是 SUM() 配合 GROUP BY。常见错误是 SELECT 里写了 product_name 和 SUM(sales_amount)，却只对 product_id 分组——这在 MySQL 5.7+、PostgreSQL、SQL Server 等严格模式下会报错：ERROR: column "product_name" must appear in the GROUP BY clause or be used in an aggregate function。
正确做法是：所有非聚合列（比如 product_name、region、year）都得出现在 GROUP BY 子句中。
- 如果按商品名分组，就写
GROUP BY product_name - 如果按年份 + 地区分组，就得写
GROUP BY year, region - 别依赖 MySQL 5.6 及更早版本的“宽松模式”，它可能返回不可靠的
product_name值
WHERE 和 HAVING 别混用：过滤行用 WHERE，过滤分组用 HAVING
WHERE 在分组前生效，HAVING 在 SUM() 计算完之后才起作用。想查“2023 年各产品的销售额”，要先用 WHERE year = 2023；但想查“销售额超 10 万的品类”，就得用 HAVING SUM(sales_amount) > 100000。
典型错误是把金额条件写在 WHERE 里，例如 WHERE SUM(sales_amount) > 100000 —— 这会直接报错：ERROR: aggregate functions are not allowed in WHERE。
-
WHERE可用字段：原始表中的任意列（如order_date、status） -
HAVING可用字段：SELECT中的别名（如total_sales）或聚合表达式（如SUM(sales_amount)） - 执行顺序固定：
FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY
NULL 值会让 SUM() 结果变 NULL？其实不会，但得注意字段本身是否可空
SUM() 会自动忽略 NULL 值，只累加非空数字。但如果整组数据的 sales_amount 全是 NULL，结果就是 NULL，不是 0。这在报表里容易造成空值显示异常。
稳妥做法是用 COALESCE(SUM(sales_amount), 0) 显式转成 0。别用 ISNULL() 或 NVL()，函数名因数据库而异：COALESCE() 是标准 SQL，所有主流数据库都支持。
- 如果源字段定义为
sales_amount DECIMAL(10,2) NULL，且业务上“未录销售额”和“销售额为 0”含义不同，那保留NULL反而是对的 - 如果只是想避免前端报错或图表空白，
COALESCE(SUM(sales_amount), 0)最安全 - 别在
SUM()外套CAST(... AS INT)除非真需要截断小数——SUM()返回类型由输入字段决定，强行转换可能丢精度
性能关键：分组字段要有索引，特别是高基数列慎用
当按 order_id 或 customer_phone 这类高基数（几乎每行都不同）字段分组时，SUM() 会生成大量分组，内存和排序开销陡增。这时候即使加了索引，查询也可能变慢甚至 OOM。
真实场景中，优先按有明确业务意义、低基数的字段分组，比如 product_category、region_code、quarter。如果必须按高基数字段聚合，考虑加 LIMIT 或预聚合到汇总表。
- 索引建议：在
GROUP BY字段 +WHERE条件字段上建联合索引，例如INDEX idx_region_year (region, year) - 避免在
GROUP BY里用函数，如GROUP BY YEAR(order_date)—— 会导致索引失效 - PostgreSQL 用户可关注
EXPLAIN ANALYZE输出里的Group Key和Sort Method，判断是否走内存排序
