Какие шаги необходимо предпринять для оптимизации неэффективного запроса?

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

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

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

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

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

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

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

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

Еще несколько общих советов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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