ROW_NUMBER()与COUNT(1) OVER分区：哪种方案更优？（SQL Server 2008+）

在SQL Server 2008及以上版本中，你提到的这两个窗口函数写法，在示例场景下输出结果看似一致，但效果和性能上其实有不少值得拆解的细节，咱们一步步说：

一、效果差异 #

先明确两者的核心计算逻辑：

• ROW_NUMBER() OVER (PARTITION BY ELEMENT ORDER BY EMPLOYEE)：在每个ELEMENT分区内，按EMPLOYEE排序后给每一行分配唯一递增的行号。哪怕EMPLOYEE存在重复值，行号也会依次递增（比如同一分区内两个相同的EMPLOYEE，会得到1和2）。

• COUNT(1) OVER (PARTITION BY ELEMENT ORDER BY EMPLOYEE)：因为加了ORDER BY，SQL Server默认窗口范围是RANGE UNBOUNDED PRECEDING AND CURRENT ROW，也就是计算从分区第一行到当前行的总行数。如果你的EMPLOYEE在每个ELEMENT分区内都是唯一的，结果和ROW_NUMBER()完全匹配（就像你给出的示例数据那样）；但如果存在重复的EMPLOYEE值，同一组重复值的行会得到相同的计数，比如：

  EMPLOYEE	ROW_NUMBER结果	COUNT(1)结果
  00000003	1	1
  00000003	2	2
  00000004	3	3

  哦不对，实际如果是RANGE范围，相同排序键的行会被归为同一组，所以上面的COUNT(1)结果应该是：第一行1，第二行2，第三行3？不，等下——如果是RANGE UNBOUNDED PRECEDING AND CURRENT ROW，对于相同的EMPLOYEE值，会包含所有等于当前值的行，所以前两行的COUNT(1)结果都会是2，第三行是3，这和ROW_NUMBER()的唯一行号差异就很明显了。

二、性能表现 #

从SQL Server查询优化器的角度看，这两个函数在你的场景下（PARTITION BY ELEMENT ORDER BY EMPLOYEE），通常会生成几乎一致的执行计划：

• 两者都需要先按ELEMENT分区，再对每个分区内的数据按EMPLOYEE排序；
• 计算逻辑上，ROW_NUMBER()是逐行递增计数，COUNT(1)是累计计数，优化器会识别这种相似性，采用类似的执行步骤（比如用排序运算符，或者利用索引避免排序）。

几个影响性能的细节：

1. 索引支持：如果表上有包含ELEMENT和EMPLOYEE的复合索引（比如CREATE INDEX IX_Table_Element_Employee ON YourTable(ELEMENT, EMPLOYEE)），两个函数都能直接利用索引跳过排序操作，性能会大幅提升，此时两者执行效率基本无差异。
2. 数据规模与重复度：如果EMPLOYEE重复度极高，COUNT(1)的累计计算可能比ROW_NUMBER()多一点点开销，但这个差异在绝大多数业务场景下可以忽略，只有超大规模数据集才可能显现。
3. 实际验证：最准确的性能判断方式是用你的真实数据集，查看两者的执行计划，对比逻辑读、CPU时间、执行时长这些指标。

三、总结 #

• 效果上：若EMPLOYEE在分区内唯一，两者结果一致；若有重复值，ROW_NUMBER()生成唯一行号，COUNT(1)生成累计到当前行的计数（重复排序键的行计数相同）。
• 性能上：两者差异极小，有合适索引时基本无区别；无索引时执行计划高度相似，性能差距可忽略。
• 选择哪种写法，核心取决于你实际需要的是唯一行号还是累计行数（尤其是存在重复排序键的场景）。

内容的提问来源于stack exchange，提问作者Daniele Palazzo