Почему производительность повышается при переходе от производной таблицы к решению временной таблицы? - PullRequest
Новая
       18

Почему производительность повышается при переходе от производной таблицы к решению временной таблицы?

6 голосов
/ 28 февраля 2012

Я читаю «Отклонение планов выполнения SQL Server» от Гранта Фричи, и мне очень помогает понять, почему некоторые запросы выполняются медленно.

Однако я озадачен этим случаем, когда выполняется простая перезаписьнамного быстрее.

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

-- 21 secs
SELECT *
  FROM Table1 AS o JOIN( 
    SELECT col1
    FROM    Table1
    GROUP BY    col1
    HAVING  COUNT( * ) > 1
) AS i ON ON i.col1= o.col1

Моя вторая попытка выполняется в 3 раза быстрее и просто перемещает производную таблицу во временную таблицу.Теперь это в 3 раза быстрее: 

-- 7 secs
SELECT col1
INTO    #doubles
FROM    Table1
GROUP BY    col1
HAVING  COUNT( * ) > 1

SELECT *
FROM Table1 AS o JOIN #doubles AS i ON i.col1= o.col1

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

Я был бы признателен, если бы кто-то мог показать мне, как я могу диагностировать эту проблему, используя (графический) план выполнения.

Xml План выполнения: https://www.sugarsync.com/pf/D6486369_1701716_16980

image

Редактировать 1

Когда я создал статистику для столбцов 2 , которые были указаны в группе, и оптимизатор начал делать "правильные вещи" после отказакеш процедур (не забывайте, что если вы новичок!).Я упростил запрос в вопросе, который не был хорошим упрощением в ретроспективе.Прикрепленный sqlplan показывает 2 столбца, но это было неочевидно.

Оценки теперь намного точнее, как и производительность, которая соответствует уровню решения временной таблицы.Как вы знаете, оптимизатор автоматически создает статистику по отдельным столбцам (если она не отключена), но администратор базы данных должен создать статистику по 2 столбцам.

Индекс (не кластеризованный) для этих 2 столбцов заставил запрос выполнить то же самоено в этом случае статистика так же хороша, и она не страдает недостатком поддержки индекса.Я иду вперед со статистикой в ​​2 столбца и посмотрю, как она работает.@ Грант Знаете ли вы, если статистика по индексу более надежна, чем статистика по столбцу?

Редактировать 2

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

Проблема здесь заключалась в том, что предполагаемое количество строк было в порядке.Графические планы выполнения показывают это, когда вы наводите курсор на строку, но это все.

Некоторые инструменты, которые могут помочь:

  1. УСТАНОВИТЬ ПРОФИЛЬ СТАТИСТИКИ НА

Я слышал, что этот файл устареет и будет заменен его вариантом XML, но мне все еще нравится вывод в формате сетки.Здесь большая разница между столбцами «Rows» и «EstimateRows» показала бы проблему

Внешний инструмент: SQL Sentry Plan Explorer http://www.sqlsentry.net/

Это хороший инструмент, особенно если вы новичок.Выделяет проблемы

enter image description here

Внешний инструмент: SSMS Tools Pack http://www.ssmstoolspack.com/

Более универсальный инструмент, но снова направляющий пользователя на потенциальные проблемы

enter image description here

ВидС уважением, Том

1 Ответ

4 голосов
/ 28 февраля 2012

Глядя на значения для первого плана выполнения, похоже, что это статистика.У вас есть приблизительное количество строк в 800 и фактическое 1,2 миллиона.Я думаю, вы обнаружите, что обновление статистики изменит способ генерации плана первого запроса.

...