SQL Server中GROUP BY字段顺序必须匹配索引最左前缀以启用流聚合，COUNT(*)为默认首选，HAVING仅过滤聚合结果，WHERE才减少分组数据量，SELECT须避免非分组非聚合列。
GROUP BY 字段顺序必须匹配索引最左前缀
SQL Server 的流聚合（Stream Aggregate）依赖输入数据在 GROUP BY 列上已排序，否则会退化为哈希聚合（Hash Aggregate），触发内存申请甚至磁盘溢出。而排序能否免去，取决于索引是否能“覆盖”分组顺序。
- 如果查询是
GROUP BY region, product，但只建了(product, region)索引，SQL Server 无法直接利用该索引做流聚合——必须额外排序，执行计划里会出现Sort节点 - 正确做法是建
(region, product)索引；若还有WHERE status = 'active'，优先把status放最左：(status, region, product) - 注意：索引字段方向（ASC/DESC）也需与
GROUP BY一致，否则仍可能失效
COUNT(*) 是默认首选，别写 COUNT(1) 或 COUNT(列名)
COUNT(*) 在 SQL Server 中被优化器直接识别为行计数指令，不检查 NULL，也不生成临时列；而 COUNT(列名) 必须逐行判空，COUNT(1) 虽无 NULL 判断，但仍是表达式计算，在旧版本中可能多一次常量求值。
- 统计总行数、分组后每组记录数，一律用
COUNT(*) - 仅当明确要排除某列 NULL 值时才用
COUNT(列名)，例如COUNT(phone)统计有手机号的用户数 - 不要因为“听说 COUNT(1) 更快”就改写——现代 SQL Server（2016+）已无性能差异，反而降低可读性
HAVING 不能减少中间结果，WHERE 才是关键
HAVING 是在所有分组完成之后才执行的过滤，它对聚合结果再筛一遍，完全不影响分组过程本身的数据量。真正影响性能的是分组前的数据规模。
- 错误写法：
GROUP BY region HAVING region IN ('华北', '华东')→ 先全表分组，再丢弃其他 region - 正确写法：
WHERE region IN ('华北', '华东') GROUP BY region→ 提前过滤掉 90% 行，分组数据量直降 - 只有基于聚合值的条件才必须用
HAVING，例如HAVING COUNT(*) > 100；这类条件无法下推到WHERE
避免 SELECT 中混用非分组非聚合列
SQL Server 默认启用 ONLY_FULL_GROUP_BY 类似行为（即使未显式开启，也常因兼容性或设置报错），一旦 SELECT 列表出现既没出现在 GROUP BY 里、也没套聚合函数的列，就会报错或返回不可靠数据。
- 典型报错：
Column 'Orders.OrderDate' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause - 常见陷阱：用
SELECT user_id, MAX(order_date), order_status——order_status没聚合也没分组，语义模糊（到底是哪一行的状态？） - 解决方式：要么加进
GROUP BY，要么用聚合包裹，如MAX(order_status)或STRING_AGG(order_status, ',')
GROUP BY 顺序的一致性——差一个字段位置，就从毫秒级变成秒级；其次是把 HAVING 当成前置过滤用，导致大表聚合卡死。这两点不调，加再多内存也白搭。 
