Я столкнулся с записью запроса differnt способами как показанный ниже Типа-I
SELECT JS.JobseekerID
, JS.FirstName
, JS.LastName
, JS.Currency
, JS.AccountRegDate
, JS.LastUpdated
, JS.NoticePeriod
, JS.Availability
, C.CountryName
, S.SalaryAmount
, DD.DisciplineName
, DT.DegreeLevel
FROM Jobseekers JS
INNER
JOIN Countries C
ON JS.CountryID = C.CountryID
INNER
JOIN SalaryBracket S
ON JS.MinSalaryID = S.SalaryID
INNER
JOIN DegreeDisciplines DD
ON JS.DegreeDisciplineID = DD.DisciplineID
INNER
JOIN DegreeType DT
ON JS.DegreeTypeID = DT.DegreeTypeID
WHERE
JS.ShowCV = 'Yes'
Ввести-II
SELECT JS.JobseekerID
, JS.FirstName
, JS.LastName
, JS.Currency
, JS.AccountRegDate
, JS.LastUpdated
, JS.NoticePeriod
, JS.Availability
, C.CountryName
, S.SalaryAmount
, DD.DisciplineName
, DT.DegreeLevel
FROM Jobseekers JS, Countries C, SalaryBracket S, DegreeDisciplines DD
, DegreeType DT
WHERE
JS.CountryID = C.CountryID
AND JS.MinSalaryID = S.SalaryID
AND JS.DegreeDisciplineID = DD.DisciplineID
AND JS.DegreeTypeID = DT.DegreeTypeID
AND JS.ShowCV = 'Yes'
Я использую базу данных Mysql
Обе работы действительно хорошо, Но я задаюсь вопросом
Заранее спасибо
1- Это и ежу понятно, используйте тип I
2- Соединение типа II также называется «неявным соединением», тогда как тип I называется «явным соединением». С современной СУБД у вас не будет проблем с производительностью обычного запроса. Но я думаю, что с каким-то большим сложным запросом с несколькими соединениями у СУБД может возникнуть проблема с неявным соединением. Использование только явного соединения может улучшить ваш план объяснения, поэтому результат будет быстрее!
3- Таким образом, производительность может быть проблемой, но, что наиболее важно, читаемость может быть улучшена для дальнейшего обслуживания. Явное соединение точно объясняет, к чему вы хотите присоединиться в каком поле, тогда как неявное соединение не отображается, если вы выполняете соединение или фильтр. Предложение Where предназначено для фильтрации, а не для объединения!
И большой важный момент для явного соединения: внешнее соединение действительно раздражает с неявным соединением. Когда вам нужно множественное соединение с внешним соединением, это так сложно читать, что явное соединение является решением.
4- План выполнения - это то, что вам нужно ( См. Документ )
Некоторые дубликаты:
Явные и неявные соединения SQL
в большинстве случаев кода, которые я видел, эти запросы выполняются так же, как ваш тип II, но я думаю, что тип I лучше из-за удобочитаемости (и большей логики - соединение - это соединение, поэтому вы следует записать его как соединение (хотя второй - это просто еще один стиль письма для внутренних объединений)).
в производительности не должно быть разницы (если она есть, думаю, Type-I будет немного быстрее).
Посмотрите на "Explain"-синтаксис http://dev.mysql.com/doc/refman/5.1/en/explain.html
Мое предложение.
Обновите все ваши таблицы, добавив некоторое количество записей. Получите доступ к консоли MySQL и выполните обе команды SQL одну за другой. Вы можете увидеть время выполнения в консоли.
Для двух упомянутых вами запросов (каждый из которых имеет только внутренние соединения) любой оптимизатор запросов современной базы данных должен выдавать точно такой же план запроса и, следовательно, такую же производительность.
Для MySQL, если вы поставите перед запросом префикс EXPLAIN
, он выдаст информацию о плане запроса (вместо выполнения запроса). Если информация из обоих запросов одинакова, план запроса будет одинаковым и производительность будет одинаковой. Из Справочного руководства MySQL :
EXPLAIN возвращает строку информации для каждой таблицы, используемой в SELECT утверждение. Таблицы перечислены в вывод в том порядке, в котором MySQL будет читать их при обработке запрос. MySQL разрешает все соединения, используя метод соединения с вложенным циклом. Это означает что MySQL читает строку с первого table, а затем находит соответствующую строку во второй таблице, в третьей таблице, и так далее. Когда все таблицы обработано, MySQL выводит выбранные столбцы и возврат через список таблиц, пока не будет найдена таблица для у которых больше совпадающих строк. Следующая строка читается из этой таблицы и процесс продолжается с следующая таблица.
Когда используется ключевое слово EXTENDED, EXPLAIN выводит дополнительную информацию которые можно просмотреть, выполнив SHOW Заявление ПРЕДУПРЕЖДЕНИЯ после Заявление EXPLAIN. Эта информация показывает, как оптимизатор квалифицируется имена таблиц и столбцов в SELECT заявление, как выглядит SELECT после применения перезаписи и правила оптимизации и, возможно, другие заметки о процессе оптимизации.
Какой синтаксис лучше? Это зависит от вас, но как только вы перейдете от внутренних соединений к внешним, вам потребуется использовать новый синтаксис, поскольку нет стандарта для описания внешних объединений с использованием старого синтаксиса неявного объединения.