Блог

У меня есть таблица в базе данных SQL Azure с ~ 2 миллионами строк. В этой таблице у меня есть две пары столбцов, которые я хочу отфильтровать по null — поэтому я отфильтровал индексы по каждой паре, проверяя наличие null в каждом столбце.

Один из индексов, по-видимому, примерно в два раза больше другого — (~ 400 000 против ~ 800 000 строк).

Однако, похоже, запрос занимает примерно в 10 раз больше времени.

Я выполняю один и тот же запрос для обоих:

 SELECT DomainObjectId 
FROM DomainObjects
INNER JOIN 
    (SELECT <id1> AS Id
     UNION ALL 
     SELECT<id2> etc...
    ) AS DomainObjectIds ON DomainObjectIds = DonorIds.Id 
WHERE C_1 IS NULL 
  AND C_2 IS NULL
  

Где C_1 / C_2 — столбцы с отфильтрованным индексом (и заменяются другими столбцами в моем другом запросе).

Оба плана запроса включают поиск по индексу, но в быстром режиме это занимает 99% времени выполнения. В медленном случае это всего лишь 50% — с другой половиной, потраченной на фильтрацию (что кажется подозрительным, учитывая, что фильтрация должна быть неявной из отфильтрованного индекса), а затем присоединением к запрошенным идентификаторам.

Кроме того, «предполагаемое количество строк для чтения» для поиска по индексу составляет ~ 2 миллиона, то есть размер полной таблицы. Исходя из этого, это выглядит так, как я ожидал бы, что будет выглядеть полное сканирование таблицы. Я проверил размеры индекса, и «медленный» индекс занимает всего в два раза больше места, чем «быстрый», что подразумевает, что он не просто был плохо сгенерирован.

Я не понимаю:

• (a) Почему так много времени тратится на повторное применение фильтра из индекса
• (b) Почему предполагаемое количество строк так велико для «медленного» индекса
• (c) Что могло привести к тому, что эти два запроса были настолько разными по скорости, учитывая сходство в отфильтрованных индексах. Я бы ожидал, что медленный будет в два раза медленнее, основываясь исключительно на количестве строк, соответствующих каждому фильтру.