在SQL数据处理的场景中，我们经常会遇到需要按照某个字段分组，然后取每组中最新或者特定顺序的一条数据的需求，很多开发者会优先选择ROW_NUMBER窗口函数来实现去重。但当表的数据量达到百万甚至千万级别时，这种去重方式的查询耗时可能会从几十毫秒飙升到几十秒，严重影响业务系统的响应速度。这类性能问题的核心诱因往往是索引设计不合理，导致数据库无法高效定位和处理数据。
ROW_NUMBER去重的基本用法
我们先来看一个典型的ROW_NUMBER去重场景，假设有一张订单表order_info，包含订单ID、用户ID、订单创建时间、订单金额等字段，现在需要查询每个用户最新的那一条订单记录，常规的SQL写法如下：
WITH ranked_order AS (
SELECT
order_id,
user_id,
create_time,
order_amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC) AS rn
FROM order_info
)
SELECT
order_id,
user_id,
create_time,
order_amount
FROM ranked_order
WHERE rn = 1;
这段SQL的逻辑是先按照user_id分组，组内按照create_time降序排序，给每个组内的记录分配一个序号，最后取序号为1的记录，也就是每个用户最新的订单。当order_info表数据量较小时，这段SQL的执行速度没有问题，但当数据量增长到千万级，执行效率就会明显下降。
ROW_NUMBER去重效率低的原因分析
我们可以通过执行计划来分析这段SQL的性能瓶颈，在没有合适索引的情况下，数据库的执行步骤通常是这样的：
- 全表扫描order_info表，读取所有符合条件的记录，这一步的IO成本会随着数据量增长线性增加
- 对扫描得到的全部记录按照user_id进行分组，然后在每个分组内按照create_time排序，排序操作会消耗大量的CPU和内存资源
- 给排序后的每个分组内的记录分配ROW_NUMBER序号
- 最后过滤出序号为1的记录返回
整个过程中最耗时的就是全表扫描和大批量的排序操作，而这两个问题都可以通过索引优化来解决。
索引优化方案
1. 创建复合覆盖索引
针对上面的查询场景，我们可以创建一个包含分区字段、排序字段和查询所需字段的复合索引，索引的设计要匹配ROW_NUMBER中的PARTITION BY和ORDER BY逻辑。对于上面的查询，合适的索引创建语句如下：
CREATE INDEX idx_user_create_cover ON order_info (user_id ASC, create_time DESC) INCLUDE (order_id, order_amount);
这里索引的前导列是user_id，匹配PARTITION BY的分组逻辑，第二列是create_time DESC，匹配组内的排序逻辑，INCLUDE子句包含了查询中需要的其他字段，这样可以形成覆盖索引，数据库不需要回表查询数据，直接从索引中就能获取所有需要的字段。
创建这个索引之后，数据库执行ROW_NUMBER查询时，可以直接按照索引的有序结构读取数据，每个user_id对应的记录已经是按照create_time降序排列好的，不需要额外的排序操作，也不需要全表扫描，只需要扫描索引中对应的数据页即可，性能会有数量级的提升。
2. 针对过滤条件的索引优化
如果查询中还包含其他的过滤条件，比如只需要查询2024年之后的订单，那么可以在索引中加入过滤条件对应的字段，比如：
CREATE INDEX idx_user_create_cover_filter ON order_info (user_id ASC, create_time DESC) INCLUDE (order_id, order_amount) WHERE create_time >= '2024-01-01 00:00:00';
这是一个过滤索引，只包含符合条件的数据，索引的体积更小，扫描速度更快，适合有固定过滤条件的查询场景。
3. 避免索引失效的情况
在创建索引之后，还要注意避免出现索引失效的情况，比如不要在索引列上做函数运算，不要使用隐式类型转换，WHERE条件中不要对索引列使用不等于、LIKE以通配符开头等操作，这些都会导致索引无法被正常使用，回到全表扫描的逻辑。
优化效果验证
我们可以在优化前后分别查看SQL的执行计划，对比关键指标：
| 对比项 | 优化前 | 优化后 |
|---|---|---|
| 扫描方式 | 全表扫描 | 索引查找 |
| 排序操作 | 需要额外排序 | 无需排序 |
| 回表次数 | 全部记录回表 | 0次（覆盖索引） |
| 千万级数据查询耗时 | 20秒以上 | 1秒以内 |
从对比可以看到，合理的索引优化可以让ROW_NUMBER去重的效率得到极大的提升，完全满足大数据量场景下的性能要求。
注意事项
需要注意索引并不是越多越好，每个索引都会占用额外的存储空间，并且在数据插入、更新、删除的时候需要维护索引，会带来额外的性能开销。所以需要根据实际的查询场景来创建必要的索引，对于不常用的查询场景，不需要创建对应的索引。另外，如果表的数据量本身很小，比如只有几万条记录，那么创建索引带来的收益可能不明显，甚至会因为维护索引带来额外的开销，这种情况可以根据实际情况选择是否优化。
SQLROW_NUMBER去重索引优化修改时间：2026-06-19 08:57:16