Пути улучшения результатов оптимизатора запросов SQL Server - PullRequest
0 голосов
/ 11 января 2010

Вопрос довольно прост: Что я могу сделать, чтобы в оптимизаторе запросов SQL Server была вся информация, необходимая для выбора «лучшего» плана запроса?

История вопроса состоит в том, что в последнее время мы сталкиваемся со все большим числом случаев, когда SQL Server выбирает неверный план запроса, т. Е. Случаи, когда добавляются подсказки запроса, подсказки объединения или явно используются временные таблицы вместо «одной большой SQL "резко улучшил производительность. Я на самом деле очень удивлен, что оптимизатор запросов дает так много плохих результатов, поэтому мне интересно, сделали ли мы что-то не так. Отсутствуют индексы (согласно анализатору запросов и здравому смыслу), а статистика часто обновляется с помощью задачи обслуживания.

Позвольте мне подчеркнуть, что я не говорю об отсутствующих индексах здесь! Я говорю о ситуации, когда существует «хороший» и «плохой» план запроса (с учетом текущего состояния БД), и SQL Server выбирает «плохой» план, хотя имеющиеся индексы позволят ему использовать "хороший план. Мне интересно, есть ли возможность улучшить результаты оптимизатора запросов без необходимости оптимизации всех запросов вручную (с подсказками запросов или USE PLAN).

Ответы [ 3 ]

2 голосов
/ 11 января 2010

Существует не только способ создания плана запроса, но не только индексы и статистика.

См. 13 вещей, которые вы должны знать о статистике и оптимизаторе запросов , для хорошего их объяснения.

1 голос
/ 11 января 2010

Я обнаружил, что слишком большой запрос можно оптимизировать, разбив его на два или более запросов, а промежуточные результаты сохраняются во временных таблицах. Я не знаю строгих правил, когда запрос становится слишком большим; простые «последовательные» внутренние объединения из 20 таблиц могут быть оптимизированы должным образом, причём причудливые запутанные объединения на 8 таблицах могут оказаться неудачными. Когда это происходит, в общем, я стараюсь «вытянуть» как можно больше в первый запрос для работы с «маленькими» таблицами и вернуть как можно меньший набор данных во временную таблицу, а затем использовать его в Второй запрос для обработки «больших» таблиц. («Малый» и «большой», конечно, полностью связаны с вашей ситуацией.)

Эмпирическое правило, которое я придумал, чтобы объяснить это, заключается в том, что некоторые запросы могут просто стать слишком большими или слишком сложными для любого «универсального» алгоритма «один размер подходит всем», чтобы иметь возможность создать оптимальный план запроса. в течение разумного промежутка времени. Короче говоря, хотя по большому счету вы можете писать запросы как один большой кусок, часто имеет смысл разбить их на управляемые куски. (Я знаю, что читал статьи на эту тему в прошлом, но эта тема встречается не слишком часто, и я не могу вспомнить, когда или где я их читал.)

1 голос
/ 11 января 2010

Оптимизатор запросов SQL Server строит свои планы на основе статистики. Если статистика не обновлена ​​или индексы были «перекошены» многими вставками или удалениями, оптимизатор иногда ошибается.

Большую часть времени он делает отличную работу. Вещи, которые вы должны проверить:

  • Ваша статистика актуальна?

  • Ваши индексы фрагментированы ?. У вас есть регулярная плановая работа по обслуживанию индекса?

  • Вы недовольны анализом параметров, вызывая кеширование неуместных планов?

  • Достаточно ли избирательны ваши данные для выбора индекса?

Я бы не использовал подсказки по запросу, если только вам не понадобится последнее средство. У них есть неприятная привычка возвращаться, чтобы преследовать тебя.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...