Какой из двух способов кодировать Внутреннее объединение быстрее?

Два запроса в OP говорят очень разные вещи и дают одинаковые результаты только в том случае, если имеются правильные предположения модели данных:

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

2. Используется первичный ключ или уникальный ключ таблицы поиска.

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

Как отмечали другие, подзапрос больше похож на внешнее соединение, поскольку он возвращает ноль для столбцов LastName, Description и Taskname вместо того, чтобы полностью фильтровать строку.

In Кроме того, если один из подзапросов возвращает более одной строки, вы получите ошибку.

Что касается личных предпочтений, я предпочитаю второй пример с синтаксисом соединения,

A lot of SQL programmers are completely unaware that the optimizer frequently resolves subqueries into joins. There is likely no cause for performance woes in either query.

View the execution plan!

Generally speaking there is no difference in the performance of simple subqueries vs joins - it is a common misconception that subqueries are much slower (because SQL server has to loop through the inner query), however generally speaking this is simply untrue! During the compilation process SQL server produces an execution tree, and often in these trees subqueries are equivalent to joins.

Its worth noting that your two queries are not logically the same and produced different results for me, the second query should actually read something along the lines of: (this still isnt identical, but its closer)

SELECT t.PKey, t.Billable, c.LastName, m.Description, lt.TaskName, t.StartTime, t.EndTime, t.SavedTime
FROM dbo.TopicLog AS t     
LEFT OUTER JOIN Contact.dbo.Contacts as c   on  c.Pkey = t.Contacts_PKey
LEFT OUTER JOIN Common.dbo.LMain  as m  on  m.PKey = t.DType
LEFT OUTER JOIN Common.dbo.LTask  as lt on lt.PKey = t.TaskType
WHERE t.StartTime > '7/9/09'
ORDER BY t.StartTime

In my testing the subquery produced an execution plan with a drastically lower number of reads (15 as opposed to 1000), however slightly higher cpu - on average the execution times were roughly equivalent.

Its worth noting however that this wont always be the case (particularly when evaluating functions inside a subquery), and sometimes you may run into problems due to a subquery. Generally speaking however its best to worry about such cases only when you run into performance problems.

Я думаю, что второй вариант выполняется быстрее. Причина этого заключается в использовании псевдонима (t, c, m и т. Д. В вашем примере). Реляционный движок имени может легко найти указатель на расположение таблицы.

Думаю, это один из советов по настройке sql.

Обычно второй (собственно внутреннее соединение). Первый (подзапросы) выполняет 3 запроса для каждой строки, но обычно это управляется компилятором, чтобы уменьшить различия.

Еще лучше: Проверьте планы выполнения запросов сами!

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

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

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

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

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

Второй пример выглядит нормально.

Вы должны знать, что старый способ выполнения внутренних соединений выглядит следующим образом:

SELECT t.PKey, t.Billable, 
 c.LastName, m.Description, lt.TaskName, 
 t.StartTime, t.EndTime, t.SavedTime
FROM 
 dbo.TopicLog as t, Contact.dbo.Contacts as c, 
 Common.dbo.LMain as m,  Common.dbo.LTask as lt   
WHERE c.Pkey = t.Contacts_PKey and t.StartTime > '7/9/09'
  AND m.PKey = t.DType
  AND lt.PKey = t.TaskType
ORDER BY  t.StartTime

И предположительно это так. эквивалентен синтаксису современного синтаксиса «внутреннее соединение таблица в поле » после его анализа.

Как говорится в другом ответе, если вы ищете более быстрые запросы, первый нужно проверить, отсортированы ли индексы таблиц.