2

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

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

4

1 回答 1

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]

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

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

于 2013-06-02T16:11:00.063 回答