小编Cor*_*son的帖子

我有一张这样的表：

CREATE TABLE Updates
(
    UpdateId INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
    ObjectId INT NOT NULL
)

本质上是跟踪 ID 增加的对象的更新。

该表的使用者将选择一个由 100 个不同对象 ID 组成的块，按UpdateId特定的UpdateId. 本质上，跟踪它停止的位置，然后查询任何更新。

我发现这是一个有趣的优化问题，因为我只能通过编写由于索引而碰巧做我想要的查询来生成最大优化的查询计划，但不保证我想要什么：

SELECT DISTINCT TOP 100 ObjectId
FROM Updates
WHERE UpdateId > @fromUpdateId

@fromUpdateId存储过程参数在哪里。

有以下计划：

SELECT <- TOP <- Hash match (flow distinct, 100 rows touched) <- Index seek

由于UpdateId正在使用索引上的搜索，结果已经很好，并且按照我想要的从最低到最高的更新 ID 排序。这会生成一个流程不同的计划，这就是我想要的。但是排序显然不能保证行为，所以我不想使用它。

这个技巧也会产生相同的查询计划（尽管有一个冗余的 TOP）：

WITH ids AS
(
    SELECT ObjectId
    FROM Updates …