SQL Server 2008中按聚集主键排序的ROW_NUMBER()查询性能缓慢问题

你遇到的这个问题在多表关联分页场景里很常见——虽然OrderProductDetail.ID是聚集主键，但多表JOIN加上ROW_NUMBER()排序时，数据库没办法高效利用这个索引，尤其是当Order.Date过滤后的结果集较大时，整个查询需要先关联所有符合条件的行，再做排序和编号，开销自然就上去了。下面给你几个针对性的解决方案：

1. 先过滤主表数据，缩小后续JOIN的范围 #

核心思路是先把符合Order.Date条件的订单ID筛选出来，再基于这些ID去关联子表，避免一开始就全表JOIN三张表。用CTE就能轻松实现：

WITH FilteredOrders AS (
    -- 先快速筛选出符合日期条件的订单ID
    SELECT ID AS OrderID
    FROM [Order]
    WHERE [Date] BETWEEN '2018-01-01 00:00:00' AND '2018-12-31 23:59:59'
),
OrderedResults AS (
    SELECT 
        ROW_NUMBER() OVER (ORDER BY opd.ID) AS RowNum,
        -- 强烈建议替换成你实际需要的字段，别用SELECT *
        o.ID AS OrderID,
        o.[Date] AS OrderDate,
        op.ID AS OrderProductID,
        opd.ID AS OrderProductDetailID,
        opd.ProductName, -- 示例字段，根据你的需求调整
        opd.Quantity
    FROM FilteredOrders fo
    JOIN OrderProduct op ON fo.OrderID = op.OrderID
    JOIN OrderProductDetail opd ON op.ID = opd.OrderProductID
)
SELECT * 
FROM OrderedResults
WHERE RowNum BETWEEN @StartRow AND @EndRow; -- 替换成你的分页参数

2. 优化索引策略，让查询走高效路径 #

索引是提升性能的关键，针对你的场景，建议创建以下几个索引：

• Order表的日期索引：快速筛选符合日期条件的订单，避免全表扫描

CREATE NONCLUSTERED INDEX IX_Order_Date ON [Order]([Date]) INCLUDE (ID);

INCLUDE ID是为了让索引覆盖查询，不需要回表取数据。

• OrderProduct表的关联索引：让JOIN操作能快速找到对应订单的产品记录

CREATE NONCLUSTERED INDEX IX_OrderProduct_OrderID ON OrderProduct(OrderID) INCLUDE (ID);

• OrderProductDetail表的关联索引：虽然它的聚集主键是ID，但JOIN时用的是OrderProductID，所以需要这个索引来加速关联

CREATE NONCLUSTERED INDEX IX_OrderProductDetail_OrderProductID ON OrderProductDetail(OrderProductID) INCLUDE (ID);
-- 如果你的查询需要其他字段，把它们也加到INCLUDE里，比如：
-- CREATE NONCLUSTERED INDEX IX_OrderProductDetail_OrderProductID ON OrderProductDetail(OrderProductID) INCLUDE (ID, ProductName, Quantity);

3. 杜绝SELECT *，只取需要的字段 #

SELECT *会强制数据库返回三张表的所有字段，不仅增加数据传输的开销，还会让索引无法有效覆盖查询（除非你把所有字段都加到INCLUDE里，这显然不现实）。换成具体需要的字段，能大幅减少内存使用和IO操作。

4. 调整排序依据（如果业务允许） #

如果业务上不强制必须按OrderProductDetail.ID排序，可以考虑用更"友好"的排序字段组合，比如Order.Date, Order.ID, OrderProduct.ID, OrderProductDetail.ID。这样排序时可以利用Order表的日期索引，后续的ID都是主键，排序效率会更高。

最后，建议你打开SQL Server的执行计划（Ctrl+M），看看查询现在的瓶颈在哪里——是全表扫描？还是键查找？根据执行计划再针对性调整索引，效果会更好。

内容的提问来源于stack exchange，提问作者PeirHwa.Soo