Каковы ваши наиболее распространенные оптимизации sql?

Интересно, какая у вас самая распространенная оптимизация sql, которую вы использовали.

Ответ 1

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

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

Ответ 2

Мой любимый список подсказок (подробно описанных здесь) выглядит следующим образом

Попробуйте ограничить набор результатов запросов с помощью предложения WHERE.
Попробуйте ограничить набор результатов запросов, вернув только те столбцы из таблицы, а не все столбцы таблицы.
Использовать представления и хранимые процедуры вместо тяжелых запросов.
По возможности старайтесь избегать использования курсоров SQL Server.
Если вам нужно вернуть общее количество строк таблицы, вы можете использовать альтернативный способ вместо оператора SELECT COUNT (*).
По возможности старайтесь использовать ограничения, а не триггеры.
Используйте табличные переменные вместо временных таблиц.
По возможности избегайте предложения HAVING.
По возможности старайтесь избегать использования предложения DISTINCT.
Включите инструкцию SET NOCOUNT ON в свои хранимые процедуры, чтобы остановить сообщение с указанием количества строк, на которые влияет оператор T-SQL.
Используйте операторы select с ключевым словом TOP или оператором SET ROWCOUNT, если вам нужно вернуть только первые n строк.
Используйте подсказку таблицы FAST number_rows, если вам нужно быстро вернуть строки "number_rows".
По возможности используйте ПО UNION ALL вместо UNION.
Не используйте подсказки оптимизатора в ваших запросах.

Ответ 3

Далеко и выше: создание индексов покрытия

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

Но также стоит упомянуть:

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

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

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

Также - использование двоичной сортировки при сравнении строк, которые находятся в известном случае, так что системе не нужно учитывать разные варианты case.

Конечно, я мог бы продолжать весь день...

Rob

Ответ 4

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

+1 memcached.

Ответ 5

Индексные внешние ключи!

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

Ответ 6

1) Мне еще не найти ситуацию, когда

SELECT Field1, Field2, (SELECT Count(*) FROM tblLinked WHERE tblLinked.Field3 = tblSource.Field3) AS TheTotal
FROM tblSource

не улучшается с помощью LEFT JOIN в производную таблицу.

SELECT Field1, Field2, IsNull(Linked.TheTotal,0) AS TheTotal
FROM tblSource
LEFT JOIN (SELECT Field3, Count(*) AS TheTotal
    FROM tblLinked
    GROUP BY Field3) AS Linked ON tblSource.Field3 = Linked.Field3

2) Не сортируйте результаты на сервере, если приложение-потребитель не может сделать это самостоятельно. Это относится нередко к веб-приложениям, но для настольных приложений клиентский ПК обычно имеет достаточную мощность и может с удовольствием сделать вид.

3) Используйте EXISTS вместо проверки количества совпадающих записей.

4) Не зацикливайтесь на выполнении запроса только в одном предложении SELECT. Разумное использование переменных таблицы (а иногда и временных таблиц) может значительно сократить обрабатываемые строки.

Ответ 7

Лучшая оптимизация, с которой я когда-либо пользовалась SQL, заключалась в том, чтобы действительно понять, что нужно делать с данными и УДАЛИТЬ тонну SQL из запроса.

Самый быстрый запрос - это запрос, который не нужно запускать.

ДЕЙСТВИТЕЛЬНО ДУМАЙТЕ, что вы делаете с данными. Вы работаете по очереди? (затем используйте код на основе набора).

Вам действительно нужно присоединиться ко всем этим таблицам?
Может ли два небольших (простых) запроса выполнять работу лучше и быстрее, чем один большой запрос?
Если вы объедините эти два запроса в один запрос, может ли он работать быстрее?

Наконец, ПРОФИЛЬ ваших запросов (EXPLAIN PLAN или SQL PROFILER) и посмотрите на "IO получает". Как правило, вы хотите уменьшить количество GET до коэффициента, равного 10 полученным в строке вывода.

Ответ 8

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

Ответ 9

Если вы говорите об общем, как в самом общем, то Indexes - это первое, что появляется в моей голове.

Это мощный метод, который часто неправильно понимается и нередко подвергается насилию.

Затем я бы поставил де-нормализацию, которая может добавить в несколько бит производительности для многих баз данных.

Оптимизация запросов является третьей, и это тоже помогает. Я использую MySQL в эти дни, и ведение журнала запросов помогает много для оптимизации.

Memcached определенно не является обычным явлением, хотя кэширование какого-то рода является частью многих сайтов на конце сценариев (ASP.Net или PHP).

Ответ 10

Обеспечение соединения таблиц в правильном порядке.

Ответ 11

Две самые важные вещи в моем опыте - меньше объединений и меньше запросов. Помимо тех, которые содержат множество специфичных для БД записей, COUNT (*) относительно медленный на PgSQL, подзапросы являются медленными для MySQL и т.д.

Ответ 12

Самая большая оптимизация, которую я использовал недавно, где довольно просто.

Храните как можно большую часть бизнес-логики на сервере sql. Aka держите свой бизнес-код на той же машине, что и сервер sql. Пусть ваша бизнес-логика возвращает как можно меньше кода обратно конечному клиенту.

Сохраняйте ваш SQL-запрос как можно "короче", как сказал Фрост, используйте отдельные операторы обновления для нескольких операторов.

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

Создайте временные таблицы для частичных объединений для ускорения объединений (не забудьте их индексировать)

Ответ 13

Я прочитал все ответы, и я не нашел подсказки для использования LIMIT и OFFSET. Это очень распространенное использование в разбивке на страницы с ссылками "prev" и "next". Но предоставление такого дисплея может потреблять больше ресурсов, чем весь остальной сайт. При смещении большого количества элементов запрос может стать очень медленным. Поэтому избегайте этих запросов.

Не считайте итоговые элементы.
Показывать только первые числа "n" (например, только 100).

Такие методы используют Google, Twitter и другие сайты. В поиске Google нет точного количества результатов. Существует только приблизительное число. Twitter не позволяет пользователю просматривать все прошлые твиты. Он показывает только последнее n число (я не могу вспомнить, сколько).

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

Ответ 14

Вот веб-сайт, который проходит все этапы оптимизации запросов. От изучения планов выполнения внесения изменений в запросы. Он был написан для людей с базовыми знаниями SQL.

Школа оптимизации SQL

Ответ 15

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

Ответ 16

Несколько советов: Используйте

delete from table where id>=1 and id<=3;

вместо

delete from table where id=1;
delete from table where id=2;
delete from table where id=3;

Также используйте 'IN' вместо синтаксиса 'OR'

Ответ 17

Избегайте использования встроенных функций, таких как convertdate, stringreplace и т.д. в ваших представлениях. Если вы не можете убедиться, что данные находятся в допустимом формате, используйте хранимые процедуры, которые выполняются чтобы "очистить" данные в соответствующих таблицах.

это неприятно, но это экономит время просмотров, то есть сохраняет пользователя в весе... ^^

Ответ 18

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