SQL Query Costing, агрегирование представления быстрее? - PullRequest
Новая
       6

SQL Query Costing, агрегирование представления быстрее?

4 голосов
/ 16 июля 2010

У меня есть таблица Sheet1 $, которая содержит 616 записей.У меня есть другая таблица, Rates $, которая содержит 47880 записей.Тарифы содержат частоту ответов для данной записи на листе в течение 90 дней с даты отправки.В течение всех 90 дней отношения записей RTS общий ответ ВСЕГДА 1 (100%)

Пример: 

Sheet1$: Record 1, 1000 QTY, 5% Response, Mail 1/1/2009

Rates$: Record 1, Day 1, 2% Response
        Record 1, Day 2, 3% Response
     Record 1, Day 90, 1% Response
     Record N, Day N, N Response

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

SELECT s.[Mail Date] + r.Day as Mail_Date, s.Quantity * s.[Expected Response Rate] * r.Response as Pieces, s.[Bounce Back Card], s.Customer, s.[Point of Entry]
  FROM Sheet1$ as s
 RIGHT OUTER JOIN Rates$ as r
            ON s.[Appeal Code] = r.Appeal
 WHERE s.[Mail Date] IS NOT NULL 
   AND s.Quantity <> 0 
   AND s.[Expected Response Rate] <> 0
   AND s.Quantity IS NOT NULL 
   AND s.[Expected Response Rate] IS NOT NULL);

Поэтому я сохраняю это как представление с именем Test_Results.Используя SQL Server Management Studio, я выполняю этот запрос и получаю в результате 211 140 записей.Прошедшее время составило 4,121 секунды, вост.Стоимость поддерева была 0,751.

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

SELECT   Mail_Date, SUM(Pieces) AS Piececount
FROM     Test_Results
GROUP BY Mail_Date

Возвращает 773 строки, и выполнение заняло всего 0,452 секунды!1.458 Est.Стоимость поддерева.

Мой вопрос, с более высокой оценкой, как это выполнялось НАСТОЛЬКО быстрее, чем само исходное представление ?!Я бы предположил, что часть может быть в том, что она возвращает строки в студию управления.Если это так, как бы я посмотрел истинную стоимость этого запроса без учета обратной связи?

Ответы [ 3 ]

3 голосов
/ 16 июля 2010

SELECT * FROM view1 будет иметь план

SELECT * FROM view2 (где view2 основан на view1) будет иметь собственный полный план

Оптимизатор достаточно умен, чтобы сделать план для view2 объединить / свернуть операции в наиболее эффективную операцию. Он только будет соблюдать семантику дизайна view1, но не обязательно использовать план для SELECT * FROM view1 и затем применять другой план для view2 - в общем, это будет совершенно другой план он сделает все возможное, чтобы получить наиболее эффективные результаты.

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

0 голосов
/ 16 июля 2010

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

Чтобы ответить на ваш вопрос, однако, если вы хотите избежать сети и отображать затраты, вы можете просто выбрать каждый результат запроса в таблицу.Просто добавьте «INTO Some_Table» после списка столбцов в предложении SELECT.

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

0 голосов
/ 16 июля 2010

Стоимость запроса не зависит от единицы измерения и просто используется оптимизатором для выбора наиболее эффективного пути выполнения конкретного запроса.Их нельзя сравнивать между запросами. Этот , хотя и старый, хорошо читается.Тогда вам, вероятно, захочется поискать книги или статьи по оптимизатору MSSQL и прочитать планы запросов, если вы действительно заинтересованы.

(Кроме того, убедитесь, что вы просматриваете фактический план выполнения,а не план объяснения ... они могут быть разными)

...