GROUP BY salesperson, region是实现“每个销售员在不同地区”聚合的最简路径，需统一地区名格式、明确NULL业务含义，并将时间过滤置于WHERE而非HAVING。
用 GROUP BY 同时分组销售员和地区
直接对 salesperson 和 region 两个字段做 GROUP BY，是实现“每个销售员在不同地区”聚合的最简路径。不能只按一个字段分组，否则会把张三在北京和上海的提成加在一起，失去地区维度。
常见错误是写成 GROUP BY salesperson 然后试图在 SELECT 里多选 region——这会报错（除非 region 在函数中或也在 GROUP BY 里）。
- 必须写成
GROUP BY salesperson, region - 若表里有重复记录或未清洗数据，先确认
commission字段为数值型，避免隐式转换失败 - 地区名含空格或大小写不一致（如 “East” 和 “east”）会导致同一地区被拆成多行，建议加
TRIM(UPPER(region))统一处理
SUM(commission) 要注意 NULL 和零值区别
SUM() 默认忽略 NULL，但把 0 当作有效值参与计算。如果业务中“未成交”记为 NULL、“成交但无提成”记为 0，那统计结果语义就不同。
容易踩的坑：有人用 COALESCE(commission, 0) 把 NULL 强制转 0 再求和，看似避免了空值，实则混淆了“无记录”和“有记录但为零”两种状态。
- 先明确业务定义：提成为
NULL是数据缺失，还是逻辑上不应存在？ - 若需保留区分，查询里别补
COALESCE；若下游系统要求非空，再考虑在应用层或视图里处理 - 用
COUNT(*)和COUNT(commission)对比，能快速发现NULL占比是否异常高
WHERE 过滤要放在 GROUP BY 前
想查“2024年Q1”的提成总额？必须把时间条件写在 WHERE 子句，而不是 HAVING。因为 HAVING 是对分组后的结果过滤，而时间筛选是单条记录级别的判断。
典型错误：把 WHERE sale_date >= '2024-01-01' 错写成 HAVING sale_date >= '2024-01-01'，会直接报错——sale_date 不在 GROUP BY 列表里，也不在聚合函数中。
- 时间字段过滤一律走
WHERE - 若需按“提成总额 > 10000”筛选销售员-地区组合，才用
HAVING SUM(commission) > 10000 - 日期格式要和字段类型匹配：MySQL 用
'2024-01-01'，SQL Server 可能需CONVERT(DATE, '20240101')
跨数据库兼容性：ORDER BY 里允许用别名但有限制
想让结果按提成从高到低排，写 ORDER BY total_commission DESC 很自然。但要注意：PostgreSQL 和 SQL Server 允许在 ORDER BY 中直接用 SELECT 里的列别名，MySQL 8.0+ 支持，老版本不支持。
更稳妥的做法是重复表达式，或确保别名定义清晰。另外，排序字段若含 NULL，不同数据库默认行为不同（有的排最前，有的最后），别依赖默认。
- 推荐写法：
ORDER BY SUM(commission) DESC，不依赖别名 - 如果用了别名如
SUM(commission) AS total_commission，在 MySQL 5.7 下必须写ORDER BY 3（按第三列）或重复表达式 - 显式控制
NULL位置：ORDER BY SUM(commission) DESC NULLS LAST（PostgreSQL/Oracle），MySQL 用ORDER BY ISNULL(SUM(commission)), SUM(commission) DESC
NULL 的业务含义——这两处一旦出错，数字看起来合理，结果却完全不可信。 
