sql-server-2008 - 替代使用 WHERE ... IN (...) 进行慢速 SQL 查询

Question

这实际上是一个更大的复杂查询的一部分。
根据查询计划，此语句的排序支配较大查询的成本。
通过具体化查询的这一部分，我验证了它主导了成本。

    select [sID], ROW_NUMBER() over (partition by [sID] order by [wordPos]) [rn], [wordPos], [wordID]
      from [FTSindex] 
     where [wordID] in (428,2112)
  order by [sID], [rn] 

从右到左:
- 索引搜索 5% (IX_FTSindex_wordID_sID)
- 排序 76%
- 并行度 19%

CREATE TABLE [dbo].[FTSindex](
    [sID] [int] NOT NULL,
    [wordPos] [int] NOT NULL,
    [wordID] [int] NOT NULL,
    [charPos] [int] NOT NULL,
 CONSTRAINT [PK_FTSindex] PRIMARY KEY CLUSTERED 
(
    [sID] ASC,
    [wordPos] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 100) ON [PRIMARY]
) ON [PRIMARY]

CREATE NONCLUSTERED INDEX [IX_FTSindex_wordID_sID] ON [dbo].[FTSindex] 
(
    [wordID] ASC,
    [sID] ASC,
    [wordPos] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 100) ON [PRIMARY]
GO

鉴于 IX_FTSindex_wordID_sID 包含 [sID] 和 [wordPos]，我认为这种排序会非常快。
单独尝试 [wordID] 和 [wordID]、[sID]，排序仍然是成本的 76%。

即使是这个查询

    select [sID], [wordPos] -- , wordID
      from [FTSindex] 
     where [wordID] in (428,2112)
  order by [sID], [wordPos]   

排序是排序是 76% 或成本。

如何才能让分拣成本降下来？
PK要保持原样。
我可以添加或修改其他索引。

Answer 1

只是为了再次咯咯地笑，你能试试这个查询吗:

  select 
    [sID], 
    ROW_NUMBER() over (partition by [sID] order by [wordPos]) [rn], 
    [wordPos], [FTSindex].[wordID]
  from [FTSindex] 
  join ( 
    values (428), (2112)
  ) w (wordID) on w.wordID = [FTSindex].wordID
  order by [sID], [rn] 

有时，投入更多硬件解决问题才是正确答案；尽管我同意这应该是最后的手段而不是第一个。这个特定问题是否需要更多 CPU、更多内存或更多主轴取决于许多因素，包括您当前的硬件。

您的结果集有 160 万行，每行 4 个整数，应该可以在任何合理数量的当前硬件上快速排序。由于发生了延迟，似乎在 9 亿行的基本集上发生了过多的处理，而挑战在于确定原因。您能否附加有关查询计划的更多详细信息？