какой запрос лучше и эффективнее - mysql - PullRequest
7 голосов
/ 29 июня 2010

Я сталкивался с написанием запроса различными способами, как показано ниже Тип-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. Есть ли какой-нибудь инструмент, где я могу проверить, какой запрос лучше?

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

Ответы [ 5 ]

10 голосов
/ 29 июня 2010

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

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

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

И большой большой смысл для явного соединения: внешнее соединение действительно раздражает неявным соединением.Когда вы хотите многократное объединение с внешним объединением, это так трудно прочитать, что явное объединение - это РЕШЕНИЕ.

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

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

Явные и неявные SQL-объединения

SQL-соединение: предложение where и предложение

ВНУТРЕННЕЕ СОЕДИНЕНИЕ против предложения WHERE

1 голос
/ 29 июня 2010

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

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

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

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

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

1 голос
/ 29 июня 2010

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

1 голос
/ 29 июня 2010

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

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

1 голос
/ 29 июня 2010

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

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

...