使用 WHERE ... IN (...) 进行慢速 SQL 查询的替代方法

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

    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必须保持原样。
我可以添加或修改其他索引。

只是为了再次咯咯笑，你可以尝试这个查询吗：

  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 亿行的基本集上发生了过多的处理，而挑战在于找出原因。您能否附上有关查询计划的更多详细信息？