Есть ли проблемы с производительностью с Inner Join? - PullRequest
8 голосов
/ 21 июля 2009

В настоящее время я использую много внутренних соединений (около 7) в моем sp, влияет ли это на производительность sp. Левое внешнее соединение дает лучшую производительность, чем внутреннее соединение.

еще одна вещь, если я соединяю две таблицы a и b, которые имеют столбцы id и id1, обе не обнуляются. я полагаю, что здесь можно перейти к внутреннему соединению, так как эти столбцы проиндексированы.

Ответы [ 6 ]

10 голосов
/ 21 июля 2009

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

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

Что я имею в виду под тупой? Не используйте оператор OR в ваших условиях соединения. Постарайтесь сохранить ваши объединения по одному сравнению, например, по внешнему ключу в одной таблице, равному первичному ключу в другой таблице. Старайтесь, чтобы все ключевые поля были напечатаны как целые числа.

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

3 голосов
/ 21 июля 2009

JOIN используется для определенной цели, а не для производительности.

LEFT OUTER JOIN используется для включения записей, для которых в таблице справа нет соответствующих записей. INNER JOIN выбирает совпадающие записи на основе некоторых критериев в обеих таблицах.

1 голос
/ 21 июля 2009

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

Однако иногда атрибуты объединения в одной таблице функционально определяют уникальный кортеж в другой таблице. в этом случае объединение может быть очень дешевым (но вам нужно будет индексировать эти атрибуты).

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

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

1 голос
/ 21 июля 2009

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

Также проверьте план выполнения, чтобы увидеть, в чем проблема.

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

0 голосов
/ 21 июля 2009

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

В одной базе данных, над которой я работал в прошлом, соединение было по частичному ключу (таблицы имели составные ключи, то есть первичный ключ со многими столбцами в нем), и в предложении where происходила дополнительная фильтрация. Фильтрация в предложении where взяла набор строк для просмотра от нескольких миллиардов до нескольких тысяч на одной стороне объединения. Присоединиться к таблице из нескольких тысяч строк было гораздо проще, чем к нескольким миллиардам. Насколько я помню, время запроса сократилось с 20 минут до 7 секунд.

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

0 голосов
/ 21 июля 2009

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

Вы можете прочитать больше здесь.

Настройка производительности SQL Server присоединяется

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