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

替代使用WHERE ... IN（...）进行慢速SQL查询

1 个答案: