Есть ли альтернатива объединениям для повышения производительности?

Question

Есть ли альтернатива объединениям для повышения производительности?

Редактировать (gbn): относится к объединить или сопоставить подзапрос с существующим предложением, которое лучше "

---

Почему никто не упомянул о соединениях с вложенными циклами?

Answer 1

Не «альтернативный» способ для JOIN, но совет для повышения производительности JOIN: в SQL Server многие люди не знают, что вы всегда должны помещать некластеризованный индекс в столбец внешнего ключа.Некоторые люди считают, что SQL Server делает это автоматически, но не делает этого.

Так что, если у вас есть таблица Customer, возможно, у нее есть первичный ключ, например, CustomerID.SQL Server автоматически добавит индекс для этого.

Однако, если у вас есть таблица Order, которая имеет отношение внешнего ключа с Customer, по умолчанию индекс для столбца Order.CustomerID отсутствует.Но такой индекс очень полезен и полезен для объединений и поисков, поэтому я всегда рекомендую эту рекомендацию: поместите индекс во все столбцы внешнего ключа в таблице.

Answer 2

Стратегии снижения производительности объединений:

• Индексация
• Денормализация
• Результаты кеширования
• Использование базы данных NoSQL (без SQL = без объединений, q.e.d.)

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

Answer 3

Использование (NOLOCK) для объединений может повысить производительность, если вы хотите / можете читать незафиксированные записи. Когда следует использовать «с (nolock)»

Answer 4

Из вашего другого вопроса

select * 
from ContactInformation c 
where exists (select * from Department d where d.Id = c.DepartmentId )

select * 
from ContactInformation c 
inner join Department d on c.DepartmentId = d.Id  

Если вы хотите получить вывод из обеих таблиц, тогда у вас есть опция, отличная от JOIN.Второй запрос здесь.

Если это медленно, то обычно:

• у вас есть первичный ключ / индексы?
• согласованные типы данных (столбцы DepartmentId / id)
• не использовать SELECT *

Answer 5

Синтаксически, нет альтернативного пути, кроме нескольких методов, которые могут помочь вам в отношении производительности запросов с очень большими объемами данных:

• Если применимо и количество возвращаемых запросом столбцов не так много, вы можете использовать INTERSECT, EXCEPT OR UNION
• Если запрос очень сложный и состоит из множества шагов на очень больших объемах данных, разделите и победите с помощью временных таблиц.
• Если запрос возвращается к отчету, представляющему некоторую информацию, которая может быть из вчерашнего изображения данных, вы можете использовать задания агента сервера sql для вычисления и сохранения результата в таблице, которая будет использоваться в качестве спины для отчета вместо запрос или в качестве альтернативы используйте индексированные представления для получения результата.
• Если некоторая информация, такая как количество строк в таблице, занимает слишком много времени, вы можете использовать таблицы метаданных таблицы, чтобы получить такую ​​информацию. Это не только для количества строк в таблице. Вы можете получить много информации из метаданных без необходимости ее расчета. (Поддерживайте связь с этим сайтом )

Answer 6

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

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

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

Answer 7

В любом нетривиальном приложении, управляемом БД, нет никакого способа ... избежать объединений.

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

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

Коррелированные подзапросы - еще одна альтернатива.

В общем, если вы хотите отточить свое мастерство, вы должны задать ... вопрос: Как писать эффективные запросы?