SQL-Ex blog

Но даже после следования всем лучшим советам, которые смог найти Гугл, их запрос был все так же плох.

Почему, почему почему?

Пусть, скажем, наш запрос выглядит так:

SELECT

    u.DisplayName,

    u.Reputation,

    p.Score, 

    p.PostTypeId

FROM dbo.Users AS u

JOIN

(

    SELECT

        p.Id,

        p.OwnerUserId,

        p.Score,

        p.PostTypeId,

        ROW_NUMBER() OVER

        (

            PARTITION BY

                p.OwnerUserId,

                p.PostTypeId

            ORDER BY

                p.Score DESC

        ) AS n

    FROM dbo.Posts AS p

) AS p

    ON  p.OwnerUserId = u.Id

    AND p.n = 1

WHERE u.Reputation >= 500000

ORDER BY u.Reputation DESC,

         p.Score DESC;

Без индекса он будет длиться вечно. Что-то около минуты.

Но с волшебным индексом, о котором мы слышали, можно все исправить!

И поэтому мы создаем этот мистический волшебный индекс.

CREATE INDEX bubble_hard_in_the_double_r

ON dbo.Posts

(

    OwnerUserId ASC, 

    PostTypeId ASC, 

    Score ASC

);

Но все же что-то странное есть в нашем плане запроса. Наш оператор Sort это... Ну, он все еще здесь.



Как ни странно, нам приходится сортировать по всем трем столбцам, включенным в нашу оконную функцию, несмотря на то, что два из них имеют порядок соответствующий индексу.

Оба OwnerUserId и PostTypeId имеют возрастающий порядок. Единственно со Score мы не придерживались скрипта, который запрашивается в порядке убывания.

Это дурацкая ситуация, как ни посмотри. Один столбец, выпадающий из порядка, вызывает сортировку трех столбцов...

Нам действительно нужен вместо этого такой индекс:

CREATE INDEX bubble_hard_in_the_double_r

ON dbo.Posts

(

    OwnerUserId ASC, 

    PostTypeId ASC, 

    Score DESC

);

Не скажу, нравится ли мне вообще этот план без параллелизма и пакетного режима, но мы уже были там раньше.