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

pap*_*zzo 2 t-sql sorting sql-server-2008

这实际上是更大的复杂查询的一部分.
根据查询计划,此语句上的排序支配较大查询的开销.
通过实现查询的这一部分,我确认它支配了成本.

    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] 
Run Code Online (Sandbox Code Playgroud)

从右到左:
- 索引寻求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
Run Code Online (Sandbox Code Playgroud)

鉴于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]   
Run Code Online (Sandbox Code Playgroud)

排序是76%或成本.

如何降低排序成本呢?
PK必须保持原样.
我可以添加或修改其他索引.

Pie*_*ens 7

只是为了再次咯咯笑,你可以试试这个查询:

  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] 
Run Code Online (Sandbox Code Playgroud)

有时,在问题上投入更多硬件是正确的答案; 虽然我同意这应该是最后的手段,而不是第一个.此特定问题是否需要更多CPU,更多内存或更多主轴取决于许多因素,包括您当前的硬件.

您的160万行结果集(每个4个整数)应该可以在任何合理数量的当前硬件上快速排序.由于延迟正在发生,似乎很可能在9亿行的基本集上发生了太多的处理,而挑战在于确定原因.你能附上关于查询计划的更多细节吗?