Какой SQL-запрос Лучше?
Этот оператор SQL-запроса:
SELECT p.id, p.[name], SUM(ps.sales_amount) AS GROSS_SALES
FROM products p
LEFT OUTER JOIN product_sales ps ON p.id = ps.product_id
GROUP BY p.id, p.[name]
лучше, чем:
SELECT SUM([t2].[value]) AS [SalesAmount], [t2].[id] AS [ProductId], [t2].[name] AS [ProductName]
FROM (
SELECT (
SELECT SUM([t1].[sales_amount])
FROM [dbo].[product_sales] AS [t1]
WHERE [t1].[product_id] = [t0].[id]
) AS [value], [t0].[id], [t0].[name]
FROM [dbo].[products] AS [t0]
) AS [t2]
GROUP BY [t2].[id], [t2].[name]
Второй является результатом запроса LINQ2SQL. Все еще находя способ переписать выражение LINQ...
Каков был бы наиболее оптимизированный SQL-запрос в примере?
Ваши мысли?Спасибо!
5 ответов
Реальный ответ - это то, что вы не можете сказать без измерения. Даже тогда вы на самом деле не знаете, если вы не измеряете на реалистичном наборе данных.
Проверьте этот пост блога (не мной), где сгенерированный SQL выглядел хуже, но выступил намного лучше. Его пример конкретно занимается подсессивами против присоединений, поэтому я думаю, что это очень актуально для вашей ситуации.
Ну, первый запрос лучше, потому что он более читабелен. Однако, поскольку второй запрос был сгенерирован, чем это объясняет его, и, поскольку вы не будете (не должны) приходится иметь дело с фактическим SQL, сгенерированным из выражения LINQ, там, вероятно, не проблема со вторым.
Я бы предположил, что двигатель SQL Server может сгладить это в стандартное соединение, как первый запрос. Если вы хотите узнать Огонь SQL Server Management Studio и посмотрите на фактический план выполнения обоих.
Как по общему утверждению, это похоже на довольно оскорбительное подзапрос, и на этой основе я предсказывал, что первый запрос будет быстрее. Почему бы не попробовать их и увидеть?
, что первым является более эффективным. В общих присоединениях лучше подзапросных. MS-SQL не всегда оптимизирует подзаряд к их логическому «объединению» эквиваленты. Запрос настолько маленький, хотя либо должно быть достаточно хорошим, и это, вероятно, не имеет значения. Вам нужно будет посмотреть план запроса , чтобы увидеть разницу, или посмотрите на обоих выполненных с использованием трассировки .
Первый также, конечно, более читаемый. Это то, что вы будете иметь тенденцию получить с Linq-to-SQL в эти дни. Конечно, весь смысл в том, что вам не нужно иметь дело с SQL самостоятельно.
История состоит в том, что запросы, сгенерированные LinQ-To-SQL, получит все более и более эффективную.
Моя догадка состоит в том, что оба должны быть одинаковыми, производительность-мудрыми. Левое соединение, вероятно, будет иметь вложенный цикл соединения, что именно то, что сделает версию подзапрос.
Но не принимайте мое слово для этого - как предлагают все остальные, проверьте план исполнения и посмотрите на себя, какой из них лучше. Или включите статистику клиента и посмотрите, какой из них занимает дольше.