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

Question

Какие методы могут быть эффективно применены для повышения производительности SQL-запросов? Существуют ли какие-либо общие правила?

Answer 1

• Используйте первичные ключи
• Избегайте выбора *
• быть как можно при построении условных операторов
• Де-нормализация часто может быть более эффективной
• Табличные переменные и временные таблицы (если они доступны) часто будут лучше, чем использование большой исходной таблицы
• Разделенные просмотров
• Применяйте индексы и ограничения

Answer 2

Я думаю, что использование анализатора SQL-запросов было бы хорошим началом.

Answer 3

В Oracle вы можете посмотреть на explain plan сравнить изменения в вашем запросе

Answer 4

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

Answer 5

Очевидная оптимизация для запросов SELECT - это обеспечение индексов столбцов, используемых для объединений или в предложениях WHERE.

Поскольку добавление индексов может замедлить запись данных, вам необходимо следить за производительностью, чтобы гарантировать, что вы не убьете производительность записи БД, но это то, где использование хорошего инструмента анализа запросов может помочь вам сделать так, чтобы вы делали балансировку.

Answer 6

Самое большое, что вы можете сделать, это искать сканирование таблицы в sql server query analyzer (убедитесь, что вы включили «план выполнения показа»). В противном случае существует множество статей в MSDN и других местах, которые будут давать хорошие советы.

Как в стороне, когда я начал учиться оптимизировать запросы, я запустил профилировщик запросов sql-сервера по трассировке, посмотрел на сгенерированный SQL и попытался выяснить, почему это было улучшением. Профилировщик запросов далеко не оптимален, но это достойный старт.

Answer 7

• Индексы
• Статистика
• на майкрософт стека, Database Engine Tuning Advisor

Answer 8

Узнайте, что происходит на самом деле под капотом - вы должны быть в состоянии понять следующие понятия в деталях:

• Индексы (не только то, что они есть, но и то, как они работают).
• Кластерные индексы против кучи выделенных таблиц.
• Текстовые и двоичные запросы и когда они могут быть выложены.
• Fill factor.
• Как записываются записи для обновления/удаления.
• Когда происходит разбиение страниц и почему.
• Статистика, и как они влияют на различные скорости запросов.
• Планировщик запросов и то, как он работает для вашей конкретной базы данных (например, в некоторых системах «select *» работает медленно, на современных MS-Sql DB, с которыми может справиться планировщик).

Answer 9

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

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

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

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

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

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

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

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

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

9. Убедитесь, что ваши столы не фрагментированы. How to Detect Table Fragmentation in SQL Server 2000 and 2005

Answer 10

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

WITH 
master AS 
(
    SELECT SSN, FIRST_NAME, LAST_NAME 
    FROM MASTER_SSN 
    WHERE STATE = 'PA' AND 
      GENDER = 'M' 
), 
taxReturns AS 
(
    SELECT SSN, RETURN_ID, GROSS_PAY 
    FROM MASTER_RETURNS 
    WHERE YEAR < 2003 AND 
      YEAR > 2000 
) 
SELECT * 
FROM master, 
    taxReturns 
WHERE master.ssn = taxReturns.ssn 

А подзапросы в сеансе с заявлением могут закончиться как же, как и вид инлайн, или автоматически генерируемых таблицы временных. Я нахожу в работе, которую я делаю, розничные данные, что примерно в 70-80% случаев, есть преимущество в производительности.

100% времени, есть техническое обслуживание.

Answer 11

Некоторые другие точки (Mine основаны на сервере SQL, поскольку каждый из БД бэкенд имеет собственные реализации они могут или не могут сохраняться для всех баз данных):

Избегайте коррелированные подзапросы в избранной части заявления, они по сути являются курсорами.

Создайте таблицы, чтобы использовать правильные типы данных, чтобы избежать необходимости применять к ним функции для получения данных. Гораздо сложнее делать математику по дате, когда вы храните свои данные как varchar, например.

Если вы обнаружите, что часто выполняете объединения, в которых есть функции, вам необходимо подумать о перепроектировании таблиц.

Если условия WHERE или JOIN включают операторы OR (которые медленнее), вы можете получить более высокую скорость, используя инструкцию UNION.

UNION ALL быстрее, чем UNION, если (и только в том случае, если) две записи взаимоисключающие и возвращают одинаковые результаты в любом случае.

НЕ СУЩЕСТВУЕТ, как правило, быстрее, чем NOT IN или с помощью соединения слева с ИНЕКЕ ID = NULL

В запросе UPDATE добавить WHERE условие, чтобы убедиться, что вы не обновляя значения, которые уже равны. Разница между обновлением 10 000 000 записей и 4 может быть весьма значительным!

Рассмотрите предварительные вычисления некоторых значений, если вы будете часто их запрашивать или для больших отчетов. Сумма значений в заказе должна выполняться только в том случае, если заказ сделан или скорректирован, а не когда вы суммируете результаты в 10 000 000 000 заказов в отчете. Предварительные вычисления должны выполняться в триггерах, чтобы они всегда были актуальными, это базовые изменения данных. И это тоже не должно быть просто число, у нас есть вычисленное поле, которое объединяет имена, которые мы используем в отчетах.

С осторожностью относитесь к скалярным UDF, они могут быть медленнее, чем ввод кода в линию.

Таблица температур, как правило, быстрее для больших наборов данных и переменных таблицы быстрее для небольших. Кроме того, вы можете индексировать временные таблицы.

Форматирование обычно выполняется быстрее в пользовательском интерфейсе, чем в SQL.

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

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

Это очень плохая идея для создания представлений, которые вызывают другие представления, которые вызывают другие представления. Вы можете обнаружить, что вы присоединяетесь к той же таблице 6 раз, когда вам нужно только один раз и создать 100 000,00 записей в базовом представлении, чтобы получить 6, которые находятся в вашем конечном результате.

При проектировании базы данных подумайте о представлении отчетности не только о пользовательском интерфейсе для ввода данных. Данные бесполезны, если они не используются, поэтому подумайте о том, как они будут использоваться после того, как они будут в базе данных, и как эти данные будут поддерживаться или проверяться. Это часто меняет дизайн. (Это одна из причин, по которой плохое представление о том, чтобы ORM проектировал ваши таблицы, он думает только об одном случае использования данных). Наиболее сложные запросы, влияющие на большинство данных, представлены в отчетах, поэтому при разработке изменений в предоставлении отчетов может значительно ускорить запросы (и упростить их).

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

И поскольку это нельзя сказать слишком часто, используйте индексы правильно, не слишком много или слишком мало. И сделайте предложения WHERE доступными (можно использовать индексы).