Какой из этих подходов имеет лучшую производительность для больших таблиц? - PullRequest
1 голос
/ 27 апреля 2009

Пусть A и B - две таблицы в схеме базы данных. А и В связаны отношением «многие к одному». Существует много B для каждого A, а B имеет столбец внешнего ключа a_id. Обе таблицы имеют идентификатор столбца первичного ключа.

Какой из следующих двух запросов работает лучше для больших наборов данных в A и B?

SELECT A.* FROM A,B WHERE A.id = B.a_id

или

SELECT A.* FROM A INNER JOIN B ON A.id = B.a_id

Или они эквивалентны?

Ответы [ 4 ]

5 голосов
/ 27 апреля 2009

Они эквивалентны для всех 4 основных систем баз данных: Oracle, SQL Server, MySQL, PostgreSQL.

Использование синтаксиса JOIN (точнее, использование STRAIGHT_JOIN вместо JOIN) поможет обеспечить необходимый порядок соединения в MySQL.

Подробности см. В этом ответе:

Также обычно считается более понятным и читабельным использование синтаксиса JOIN.

Хотя я вырос на Oracle примерах кода, которые обычно используют синтаксис WHERE.

1 голос
/ 27 апреля 2009

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

0 голосов
/ 27 апреля 2009

Они эквивалентны. Но вторая форма является предпочтительным синтаксисом.

0 голосов
/ 27 апреля 2009

Насколько я понимаю, они оба одинаковы. Теоретически, я полагаю, что ВНУТРЕННЕЕ СОЕДИНЕНИЕ может быть оптимизировано движком, поскольку поведение по умолчанию для A, B будет декартовым объединением. Тем не менее, я имею дело с таблицей приличного размера, и в SQL Server 2005 оба запроса давали одинаковое время запроса, поэтому я предполагаю, что механизм достаточно умен, чтобы поднять это.

Приветствия
Eric

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