ЕСТЕСТВЕННОЕ СОЕДИНЕНИЕ немного лучше, чем ВЫБОР ИЗ ГДЕ с точки зрения производительности? [дубликат]

В зависимости от обстоятельств.

Естественное соединение связывает все столбцы в двух таблицах с одинаковым именем. Если только два столбца в таблицах 1 и 2 с одинаковым именем являются идентификаторами, то оптимизатор должен одинаково оценивать эти два запроса; с другой стороны, если в двух таблицах больше двух столбцов с одинаковым именем (или их нет вообще), выполняется совершенно другой запрос.

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

Насколько хорошо ваш руководитель отличает свою большую ягодичную мышцу от верхнего конца своей локтевой кости?

Первое, на что следует обратить впору, это то, что оптимизаторы баз данных интерпретируют синтаксис по-своему. Очевидно, что каждый продукт варьируется, но я был бы откровенно удивлен, если бы какая-либо СУБД оштрафовала за то, что является наиболее распространенным механизмом объединения таблиц.

Что касается терминологии, то это перекрестное соединение, которое генерирует декартово произведение. Это отличается от внутреннего соединения и приведет к созданию другого результистрающего набора.

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

Правильный способ должен быть явным с разделенными фильтрами и объединениями

SELECT * FROM table1 JOIN table2 ON table1.id = table2.id

НАТУРАЛЬНЫЕ СОЕДИНЕНИЯ могут быть простыми и "чистыми", но, скорее всего, совершенно непредсказуемыми ...

Edit, май 2012 г.

Принятый ответ для дубликата на самом деле не отвечает NATURAL JOIN.
Эти ссылки обсуждают более подробно.

• https://dba.stackexchange.com/a/6917/630 (DBA.SE)
• Естественное соединение в SQL Server
• SQL Server - отсутствие NATURAL JOIN / x JOIN y USING ( field)
• SQL JOIN: есть ли разница между USING, ON или WHERE?

tl; dr

Производительность не является проблемой: но ваши запросы должны быть надежными и предсказуемыми, а NATURAL JOIN определенно не является .

"JOIN in the WHERE" или подразумеваемое JOIN, также известное как "декартово", также неверно согласно этим ссылкам (то же самое относится к Oracle и SQL Server)

По производительности разницы нет. Это обсуждалось снова и снова. Поиск в Google по запросу "объединить синтаксис oracle vs where" приводит к нескольким хорошим статьям, в том числе к статье на этом сайте, на которую ссылается Александр.

Однако будьте осторожны при использовании NATURAL JOIN. Он выбирает общие столбцы, такие как createdate или createuser, или такие, к которым вы обычно не заботитесь о присоединении, и может вызвать проблемы. Я настоятельно рекомендую не использовать NATURAL JOIN в производстве ... просто используйте INNER JOIN и укажите столбцы.

Даже Том соглашается .

Я бы не стал использовать ни один из синтаксисов. Ваш запрос указывает на внутреннее соединение, я бы использовал для этого явный синтаксис. Вы никогда не должны использовать подразумеваемые соединения, они могут быть неверно истолкованы (было ли это случайным перекрестным соединением или вы хотели это сделать?) И случайными перекрестными соединениями. Вы бы использовали код C #, который был заменен 18 лет назад на лучший синтаксис (ну, на самом деле C # не существовало 18 лет назад, но я думаю, вы понимаете, о чем я говорю)? Тогда почему вы используете устаревший код SQL?

Не только подразумеваемое соединение является проблемой для обслуживания, но может стать большой проблемой, если вы попытаетесь использовать синтаксис подразумеваемого соединения для внешних соединений, поскольку это не работает правильно в некоторых базах данных и, насколько мне известно, устарел по крайней мере в одной базе данных, SQL Server. И если вам нужен фильтр для таблицы в левом соединении, вы вообще не можете сделать это с подразумеваемым синтаксисом, потому что он преобразует его во внутреннее соединение.

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

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