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

Question

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

Похожие вопросы:
Какие общие методы могут применяться для оптимизации запросов SQL?

Answer 1

1. Посмотрите на план выполнения в анализаторе запросов
2. Посмотрите, какой шаг стоит больше всего
3. Оптимизируй шаг!
4. Вернуться к шагу 1 [thx to Vinko ]

Answer 2

В SQL Server вы можете посмотреть план запросов в Query Analyzer или Management Studio. Это скажет вам приблизительный процент времени, потраченного на каждую группу утверждений. Вам нужно искать следующее:

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

Некоторые другие общие советы:

• Большое количество условных операторов, таких как несколько операторов if-else, может заставить SQL Server постоянно перестраивать план запроса. Вы можете проверить это с помощью Profiler.
• Убедитесь, что разные запросы не блокируют друг друга, например, оператор обновления блокирует оператор выбора. Этого можно избежать, указав подсказку (nolock) в операторах выбора SQL Server.
• Как уже упоминалось, попробуйте мастер настройки производительности в Management Studio.

Наконец, я настоятельно рекомендую создать набор нагрузочных тестов (с использованием Visual Studio 2008 Test Edition), которые вы можете использовать для моделирования поведения вашего приложения при работе с большим количеством запросов. Некоторые узкие места производительности SQL проявляются только в этих условиях, и возможность их воспроизвести значительно облегчает их устранение.

Answer 3

Индексы могут быть хорошим местом для начала ...

Низко висящие фрукты можно сбить с помощью SQL Server Индекс Мастер настройки .

Answer 4

Есть несколько вещей, на которые вы можете обратить внимание, чтобы оптимизировать производительность вашего запроса.

1. Убедитесь, что у вас просто минимум данных. Убедитесь, что вы выбрали только те столбцы, которые вам нужны. Уменьшите размеры полей до минимума.

2. Рассмотрите возможность нормализации вашей базы данных, чтобы уменьшить количество соединений

3. Избегайте циклов (т.е. извлекайте курсоры), придерживайтесь операций установки.

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

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

6. Используйте план выполнения, чтобы увидеть, как выполняется обработка. Чего вы хотите избежать, так это сканирования таблицы, так как это дорого.

7. Убедитесь, что функция Auto Statistics включена. SQL нуждается в этом, чтобы помочь определить оптимальное выполнение. См. Большой пост Майка Гандерлоя для получения дополнительной информации. Основы статистики в SQL Server 2005

8. Убедитесь, что ваши индексы не фрагментированы Сокращение фрагментации индекса SQL Server

9. Убедитесь, что ваши таблицы не фрагментированы. Как обнаружить фрагментацию таблицы в SQL Server 2000 и 2005

Answer 5

Я не уверен насчет других баз данных, но для SQL Server я рекомендую план выполнения. Он очень четко (хотя и с большим количеством вертикальной и горизонтальной прокрутки, если у вас нет 400-дюймового монитора!) Показывает, какие шаги вашего запроса затягивают время.

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

После нескольких настроек вы можете обнаружить, что на самом деле нет никаких шагов, которые бы выделялись среди других, то есть все они по 1-2%. Если это так, то вам, возможно, потребуется выяснить, есть ли способ сократить объем данных, включенных в ваш запрос, включить ли эти четыре миллиона закрытых заказов в запрос «Активные заказы на продажу». ? Нет, поэтому исключите всех, у кого STATUS = 'C' ... или что-то в этом роде.

Еще одно улучшение, которое вы увидите в плане выполнения, - это поиск по закладкам, в основном он находит совпадение в индексе, но затем SQL Server должен быстро просмотреть таблицу, чтобы найти нужную запись. Эта операция может иногда занимать больше времени, чем простое сканирование таблицы, если это так, нужен ли вам этот индекс?

В случае индексов, и особенно в SQL Server 2005, вам следует обратиться к предложению INCLUDE, это в основном позволяет вам иметь столбец в индексе, фактически не входя в индекс, поэтому если все данные, необходимые для запроса, находятся Ваш индекс или является включенным столбцом, тогда SQL Server не нужно даже смотреть на таблицу, что значительно повышает производительность.

Answer 6

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

Как только вы выясните, где, пришло время заняться тем, как и почему. Посмотрите на тип запросов, которые вы пытаетесь выполнить. Избегайте петель любой ценой, поскольку они медленные. Избегайте курсоров любой ценой, потому что они медленные. Придерживайтесь, чтобы установить основанные запросы, когда это возможно.

Есть способы дать sql подсказки о типе объединений, которые будут использоваться, если вы используете объединения. Будьте осторожны, хотя, хотя один совет может ускорить ваш запрос один раз, он может замедлить ваш запрос в 10 раз в следующий раз, в зависимости от данных и параметров.

Наконец, убедитесь, что ваша база данных хорошо проиндексирована. Хорошее место для начала - любое поле, содержащееся в предложении where, вероятно, должно иметь индекс.

Answer 7

Посмотрите на индексы в таблицах, которые делают запрос. Индексы могут быть необходимы для определенных полей, которые участвуют в предложении where. Также посмотрите на поля, используемые в соединениях в запросе (если объединения существуют). Если индексы уже существуют, посмотрите на тип индекса.

Если это не удастся (из-за недостатков использования подсказок блокировки), посмотрите на подсказки блокировки и явно укажите индекс для использования в соединении. Использование NOLOCKS более очевидно, если вы получаете много заблокированных транзакций.

Делайте то, что упоминали Роман и Энди С. первым.