GROUP BY不保证顺序，必须显式用ORDER BY排序；ORDER BY须在GROUP BY后，且只能引用SELECT列或其别名，否则报错或行为不可靠。
GROUP BY后结果乱序，必须加ORDER BY
SQL Server不保证GROUP BY输出顺序——哪怕你建了索引、表有聚簇主键、甚至观察到连续十次查询都“看起来有序”，下次执行仍可能变乱。这不是bug，是标准行为。一旦你依赖这个“假秩序”做分页、导出或前端渲染，就容易出现重复行、错位、漏数据。
正确做法只有一条：ORDER BY必须显式写在GROUP BY之后，且只能引用SELECT列表中的列（或其别名）。
-
SELECT dept, COUNT(*) AS cnt FROM emp GROUP BY dept ORDER BY cnt DESC✅ 安全可靠 -
SELECT dept, COUNT(*) FROM emp GROUP BY dept ORDER BY create_time❌create_time不在SELECT中，报错 -
SELECT dept, COUNT(*) FROM emp GROUP BY dept ORDER BY 1❌ 位置序号可读性差，SELECT一改就崩
避免ORDER BY触发额外排序（Using filesort）
当GROUP BY和ORDER BY字段顺序不一致，或缺少匹配索引时，SQL Server会先分组（可能用哈希或排序），再对结果集二次排序，执行计划里会出现Sort算子，I/O和CPU开销陡增。
关键不是“有没有索引”，而是“索引字段顺序是否严格匹配GROUP BY + ORDER BY的组合”：
- 若语句是
GROUP BY region, status ORDER BY region ASC, status DESC，索引应为(region, status)，且方向需与ORDER BY一致（SQL Server支持混合方向，但ASC/DESC要明确） - 若
WHERE还有过滤条件（如WHERE year = 2024），把year放索引最左：(year, region, status)，这样能先过滤再分组 - 不要建
(status, region)去应付GROUP BY region, status——SQL Server大概率不走索引，退化为哈希聚合+Sort
HAVING不是性能优化点，WHERE才是
HAVING是在分组完成之后才执行的，它对已聚合的结果集做筛选，完全不影响分组过程的数据量。很多人误以为HAVING COUNT(*) > 10能“减少分组压力”，其实所有分组都算完了，再筛掉90%的组，白干。
真正省资源的方式，是把能下推的条件全塞进WHERE：
- 错误：
SELECT dept, AVG(salary) FROM emp GROUP BY dept HAVING dept IN ('tech', 'sales')→ 全表分组后再筛 - 正确：
SELECT dept, AVG(salary) FROM emp WHERE dept IN ('tech', 'sales') GROUP BY dept→ 只读两部门数据，分组范围直接缩小95% - 更进一步：如果
dept选择性低（比如只有5个值），但hire_date > '2020-01-01'能过滤80%数据，就把日期条件放WHERE最前面
聚合字段含NULL或类型混杂时，排序更容易失控
当ORDER BY字段存在大量NULL，SQL Server默认把NULL排在最前（ASC）或最后（DESC），但具体行为受SET ANSI_NULLS和兼容级别影响；若该字段是VARCHAR却混着数字字符串（如'1', '10', '2'），字典序排序会变成'1', '10', '2'，而非数值序。
这类问题不会报错，但结果不符合业务预期：
- 对数值型聚合结果排序，确保字段是
INT/DECIMAL，别用VARCHAR存金额或计数 - 需要
NULL排末尾？显式写ORDER BY ISNULL(cnt, 0) DESC或ORDER BY cnt DESC NULLS LAST（SQL Server 2022+ 支持） - 字符串数字排序：用
CAST(col AS INT)或建计算列索引，别在ORDER BY里实时转换——会阻断索引使用
实际调优时，最常被忽略的是：你以为加了索引就万事大吉，但只要GROUP BY和ORDER BY字段顺序稍有错位，或者WHERE条件没前置，SQL Server就会默默切到低效路径。盯紧执行计划里的Sort和Hash Match (Aggregate)节点，比反复改SQL更管用。
