какой запрос лучше и эффективен - mysql

Я столкнулся с записью запроса 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. который является лучшей практикой для использования всего времени для какой-либо ситуации?
  2. Производительность, мудрая, который является лучшим? (Скажите базу данных как миллионы записей),
  3. Какие-либо преимущества одного по другому?
  4. Есть ли какой-либо инструмент, где я могу проверить, который является лучшим запросом?

Заранее спасибо

7
задан gmhk 29 June 2010 в 07:39
поделиться

5 ответов

1- Это и ежу понятно, используйте тип I

2- Соединение типа II также называется «неявным соединением», тогда как тип I называется «явным соединением». С современной СУБД у вас не будет проблем с производительностью обычного запроса. Но я думаю, что с каким-то большим сложным запросом с несколькими соединениями у СУБД может возникнуть проблема с неявным соединением. Использование только явного соединения может улучшить ваш план объяснения, поэтому результат будет быстрее!

3- Таким образом, производительность может быть проблемой, но, что наиболее важно, читаемость может быть улучшена для дальнейшего обслуживания. Явное соединение точно объясняет, к чему вы хотите присоединиться в каком поле, тогда как неявное соединение не отображается, если вы выполняете соединение или фильтр. Предложение Where предназначено для фильтрации, а не для объединения!

И большой важный момент для явного соединения: внешнее соединение действительно раздражает с неявным соединением. Когда вам нужно множественное соединение с внешним соединением, это так сложно читать, что явное соединение является решением.

4- План выполнения - это то, что вам нужно ( См. Документ )

Некоторые дубликаты:

Явные и неявные соединения SQL

Соединение SQL: предложение where vs. предложение on

INNER JOIN ON vs WHERE clause

10
ответ дан 6 December 2019 в 15:18
поделиться

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

в производительности не должно быть разницы (если она есть, думаю, Type-I будет немного быстрее).

1
ответ дан 6 December 2019 в 15:18
поделиться

Посмотрите на "Explain"-синтаксис http://dev.mysql.com/doc/refman/5.1/en/explain.html

1
ответ дан 6 December 2019 в 15:18
поделиться

Мое предложение.

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

1
ответ дан 6 December 2019 в 15:18
поделиться

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

Для MySQL, если вы поставите перед запросом префикс EXPLAIN , он выдаст информацию о плане запроса (вместо выполнения запроса). Если информация из обоих запросов одинакова, план запроса будет одинаковым и производительность будет одинаковой. Из Справочного руководства MySQL :

EXPLAIN возвращает строку информации для каждой таблицы, используемой в SELECT утверждение. Таблицы перечислены в вывод в том порядке, в котором MySQL будет читать их при обработке запрос. MySQL разрешает все соединения, используя метод соединения с вложенным циклом. Это означает что MySQL читает строку с первого table, а затем находит соответствующую строку во второй таблице, в третьей таблице, и так далее. Когда все таблицы обработано, MySQL выводит выбранные столбцы и возврат через список таблиц, пока не будет найдена таблица для у которых больше совпадающих строк. Следующая строка читается из этой таблицы и процесс продолжается с следующая таблица.

Когда используется ключевое слово EXTENDED, EXPLAIN выводит дополнительную информацию которые можно просмотреть, выполнив SHOW Заявление ПРЕДУПРЕЖДЕНИЯ после Заявление EXPLAIN. Эта информация показывает, как оптимизатор квалифицируется имена таблиц и столбцов в SELECT заявление, как выглядит SELECT после применения перезаписи и правила оптимизации и, возможно, другие заметки о процессе оптимизации.

Какой синтаксис лучше? Это зависит от вас, но как только вы перейдете от внутренних соединений к внешним, вам потребуется использовать новый синтаксис, поскольку нет стандарта для описания внешних объединений с использованием старого синтаксиса неявного объединения.

1
ответ дан 6 December 2019 в 15:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: