Alternative to using WHERE … IN (…) for slow SQL queries

前端 未结 1 691
南旧
南旧 2021-01-23 04:09

This is actually part of a much larger complex query.
According to the query plan the sort on this statement dominates the cost of the larger query.
And by materializing

相关标签:
1条回答
  • 2021-01-23 04:26

    Just for giggles again, could you try this query:

      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] 
    

    Sometimes, throwing more hardware at the problem is the correct answer; though I agree that this should be a last resort and not a first. Whether this particular problem requires more CPU, more memory, or more spindles is dependent on many factors, including your present hardware.

    Your result set of 1.6 million rows, each 4 integers, should sort quickly on any reasonable amount of current hardware. Since delays are occurring it seems likely that too much processing is occurring on the base set of 900 million rows, and the challenge is to identify why. Can you attach more details about the query plan?

    0 讨论(0)
提交回复
热议问题