Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
Колеги, сделал вчера вечером интересное наблюдение, что запрос типа

SELECT FS.CreditDDID,
		   TDebit.DebitDDID,
		   FS.ItemID,
		   (
			CASE WHEN QDebit1 < QKredit1 THEN QDebit1 ELSE QKredit1 END -
		    CASE WHEN QDebit1-QDebit > QKredit1-QKredit THEN QDebit1-QDebit ELSE QKredit1-QKredit END
		   ) AS Qty	,
		   @StockID	
	FROM 
	(	SELECT d.ItemID,
			   d.RowID AS DebitRowID,
			   k.RowID AS CreditRowID,
			   d.Qty AS QDebit,
			   k.Qty AS QKredit,
			   (SELECT SUM(d1.Qty) FROM #ODebit d1 WHERE d.ItemID=d1.ItemID AND d1.RowID<=d.RowID) AS QDebit1,
			   (SELECT SUM(k1.Qty) FROM #Okredit k1 WHERE k.ItemID=k1.ItemID AND k1.RowID<=k.RowID) AS QKredit1,
			   k.CreditDDID
		FROM #ODebit d INNER JOIN #Okredit k ON d.ItemID=k.ItemID
	)   FS INNER JOIN #ODebit TDebit ON TDebit.RowID=FS.DebitRowID
	
		WHERE (CASE WHEN QDebit1 < QKredit1 THEN QDebit1 ELSE QKredit1 END -
		       CASE WHEN QDebit1-QDebit > QKredit1-QKredit THEN QDebit1-QDebit ELSE QKredit1-QKredit END) > 0
	
		ORDER BY TDebit.RowID DESC, FS.CreditRowID ASC

с использованием временных таблиц работает гораздо быстрее, чем если бы заместо них использовалиь табличные переменные. Чем это объясняется, или у меня глюки ?
24 авг 05, 07:41    [1812081]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
daw
Member

Откуда: Муром -> Москва
Сообщений: 7381
планы выполнения смотрите. сам несколько раз наблюдал, как тупая замена #table на @table приводит к совершенно другому плану выполнения. и какой из них окажется лучше - фиг угадаешь...
24 авг 05, 07:49    [1812086]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
daw
планы выполнения смотрите. сам несколько раз наблюдал, как тупая замена #table на @table приводит к совершенно другому плану выполнения. и какой из них окажется лучше - фиг угадаешь...


интересно, а что на этот счет рекомендует MS?
24 авг 05, 07:50    [1812088]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Easygoing
daw
планы выполнения смотрите. сам несколько раз наблюдал, как тупая замена #table на @table приводит к совершенно другому плану выполнения. и какой из них окажется лучше - фиг угадаешь...


интересно, а что на этот счет рекомендует MS?
Рекомендует, где только можно, применять табличные переменные.
24 авг 05, 08:00    [1812105]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
я тоже придерживался этой точки зрения, пока вчера не обратил внимание на разность скорости выполнения в несколько раз по сравнению со временной таблицей, все это как-то загадочно...
24 авг 05, 08:02    [1812112]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Easygoing
я тоже придерживался этой точки зрения, пока вчера не обратил внимание на разность скорости выполнения в несколько раз по сравнению со временной таблицей, все это как-то загадочно...
А планы то что показывают? В чем отличие (наверняка во временных табличках понастроено индексов, а в переменной даже ПК не объявлен)?
24 авг 05, 08:09    [1812118]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
tpg
Easygoing
я тоже придерживался этой точки зрения, пока вчера не обратил внимание на разность скорости выполнения в несколько раз по сравнению со временной таблицей, все это как-то загадочно...
А планы то что показывают? В чем отличие (наверняка во временных табличках понастроено индексов, а в переменной даже ПК не объявлен)?


объявления у них абсолютно одинаковые

CREATE TABLE #Okredit
(
RowID INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
CreditDDID INT UNIQUE,
ItemID CHAR(18) NOT NULL,
Qty INT NOT NULL
)

или

DECLARE @Okredit TABLE
(
RowID INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
CreditDDID INT UNIQUE,
ItemID CHAR(18) NOT NULL,
Qty INT NOT NULL
)
24 авг 05, 08:11    [1812120]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
aleks2
Guest
Easygoing
daw
планы выполнения смотрите. сам несколько раз наблюдал, как 2) тупая замена #table на @table приводит к совершенно другому плану выполнения. и какой из них окажется лучше - фиг угадаешь...


1) интересно, а что на этот счет рекомендует MS?


1) MS рекомендует @Table - они не участвуют в транзакции => это быстрее.
2) Именно "тупая", замена "с умом" обычно ускоряет процесс (или как минимум не замедляет).
24 авг 05, 08:12    [1812121]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
daw
Member

Откуда: Муром -> Москва
Сообщений: 7381
вообще, на сколько я наблюдал, для табличных переменных строятся, как правило, планы с меньшей стоимостью выполнения, что, однако, приводит время от времени к тому, что выполняются такие запросы дольше, чем для временных таблиц... иногда, даже в разы...
но это чисто субъективное мнение, вполне возможно, что просто наблюдал слишком мало :)
24 авг 05, 08:13    [1812123]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
RENaissance
Member

Откуда: Муром->Москва
Сообщений: 10895
Я обратил внимание, что при использовании табличных переменных, сервер, строя план выполнения, практически всегда использует loop join'ы при объединении табличной переменной с другими таблицами (или их с ней). При этом, сервер не смотрит на количество записей в табличной переменной. Из-за этого, относительно часто, время выполнения запроса бывает значительно больше, чем при использовании временных таблиц, т.к. loop join далеко не всегда бывает достаточно эффективным
24 авг 05, 08:14    [1812124]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
VladRUS.ca
Member

Откуда: Toronto
Сообщений: 1172
Ради интереса - заверните Ваш запрос в 2 разные процедуры с @TABLE и #TABLE и сравните время выполнения уже откомпелированных процедур.
24 авг 05, 08:33    [1812144]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
VladRUS.ca
Ради интереса - заверните Ваш запрос в 2 разные процедуры с @TABLE и #TABLE и сравните время выполнения уже откомпелированных процедур.


он ужа в процедуре :) разница ахудивительная (разы)!
24 авг 05, 08:37    [1812148]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
И, всё же, планы привести можно?
24 авг 05, 08:44    [1812158]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
ок, через некоторое время, они так долго выполняются :)
24 авг 05, 08:45    [1812160]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
VladRUS.ca
Member

Откуда: Toronto
Сообщений: 1172
Здесь Brian Moran пишит о том же http://www.windowsitpro.com/SQLServer/Article/ArticleID/40404/40404.html
24 авг 05, 08:47    [1812163]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
aleks2
Guest
Easygoing
Колеги, сделал вчера вечером интересное наблюдение, что запрос типа

SELECT FS.CreditDDID,
		   TDebit.DebitDDID,
		   FS.ItemID,
		   (
			CASE WHEN QDebit1 < QKredit1 THEN QDebit1 ELSE QKredit1 END -
		    CASE WHEN QDebit1-QDebit > QKredit1-QKredit THEN QDebit1-QDebit ELSE QKredit1-QKredit END
		   ) AS Qty	,
		   @StockID	
	FROM 
	(	SELECT d.ItemID,
			   d.RowID AS DebitRowID,
			   k.RowID AS CreditRowID,
			   d.Qty AS QDebit,
			   k.Qty AS QKredit,
			   (SELECT SUM(d1.Qty) FROM #ODebit d1 WHERE d.ItemID=d1.ItemID AND d1.RowID<=d.RowID) AS QDebit1,
			   (SELECT SUM(k1.Qty) FROM #Okredit k1 WHERE k.ItemID=k1.ItemID AND k1.RowID<=k.RowID) AS QKredit1,
			   k.CreditDDID
		FROM #ODebit d INNER JOIN #Okredit k ON d.ItemID=k.ItemID
	)   FS INNER JOIN #ODebit TDebit ON TDebit.RowID=FS.DebitRowID
	
		WHERE (CASE WHEN QDebit1 < QKredit1 THEN QDebit1 ELSE QKredit1 END -
		       CASE WHEN QDebit1-QDebit > QKredit1-QKredit THEN QDebit1-QDebit ELSE QKredit1-QKredit END) > 0
	
		ORDER BY TDebit.RowID DESC, FS.CreditRowID ASC

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


Будешь тут долго работать...

нахрен это соединение? ) FS INNER JOIN #ODebit TDebit ON TDebit.RowID=FS.DebitRowID

SELECT FS.CreditDDID,
		   FS.DebitDDID,
		   FS.ItemID,
		   (
			CASE WHEN QDebit1 < QKredit1 THEN QDebit1 ELSE QKredit1 END -
		    CASE WHEN QDebit1-QDebit > QKredit1-QKredit THEN QDebit1-QDebit ELSE QKredit1-QKredit END
		   ) AS Qty	,
		   @StockID	
	FROM 
	(	SELECT d.ItemID,
			   d.DebitDDID
			   d.RowID AS DebitRowID,
			   k.RowID AS CreditRowID,
			   d.Qty AS QDebit,
			   k.Qty AS QKredit,
			   (SELECT SUM(d1.Qty) FROM #ODebit d1 WHERE d.ItemID=d1.ItemID AND d1.RowID<=d.RowID) AS QDebit1,
			   (SELECT SUM(k1.Qty) FROM #Okredit k1 WHERE k.ItemID=k1.ItemID AND k1.RowID<=k.RowID) AS QKredit1,
			   k.CreditDDID
		FROM #ODebit d INNER JOIN #Okredit k ON d.ItemID=k.ItemID
	)   FS 
	
		WHERE (CASE WHEN QDebit1 < QKredit1 THEN QDebit1 ELSE QKredit1 END -
		       CASE WHEN QDebit1-QDebit > QKredit1-QKredit THEN QDebit1-QDebit ELSE QKredit1-QKredit END) > 0
	
		ORDER BY FS.DebitRowID DESC, FS.CreditRowID ASC

А ежели еще и коррелированные запросы убрать - вопще летать будет.
24 авг 05, 08:58    [1812176]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
VladRUS.ca
Member

Откуда: Toronto
Сообщений: 1172
А вот что пишет здесь по этому поводу сам Microsoft:
INF: Frequently Asked Questions - SQL Server 2000 - Table Variables
Q5: Do I have to use table variables instead of temporary tables?

A5: The answer depends on these three factors:
• The number of rows that are inserted to the table.
• The number of recompilations the query is saved from.
• The type of queries and their dependency on indexes and statistics for performance.

In some situations, breaking a stored procedure with temporary tables into smaller stored procedures so that recompilation takes place on smaller units is helpful.

In general, you use table variables whenever possible except when there is a significant volume of data and there is repeated use of the table. In that case, you can create indexes on the temporary table to increase query performance. However, each scenario may be different. Microsoft recommends that you test if table variables are more helpful than temporary tables for a particular query or stored procedure.
24 авг 05, 09:12    [1812190]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
VladRUS.ca
Здесь Brian Moran пишит о том же http://www.windowsitpro.com/SQLServer/Article/ArticleID/40404/40404.html


несколько разница с

tpg
Рекомендует, где только можно, применять табличные переменные.
24 авг 05, 09:13    [1812192]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
VladRUS.ca
Member

Откуда: Toronto
Сообщений: 1172
У Вас происходит именно многократное обращение к темр таблице при котором и проигрывает табличная переменная
...
(SELECT SUM(d1.Qty) FROM #ODebit d1 WHERE d.ItemID=d1.ItemID AND d1.RowID<=d.RowID) AS QDebit1,
...
24 авг 05, 09:21    [1812200]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
И так, для временной таблицы:

exec dbo.p_outcome_by_consignment @Date='01.01.2006',@StockID=19301,@DoQCheck=0

SELECT FS.CreditDDID,      TDebit.DebitDDID,      FS.ItemID,      (    CASE WHEN QDebit1 < QKredit1 THEN QDebit1 ELSE QKredit1 END -       CASE WHEN QDebit1-QDebit > QKredit1-QKredit THEN QDebit1-QDebit ELSE QKredit1-QKredit END      ) AS Qty ,      @Stock
  |--Sort(ORDER BY:([TDebit].[RowID] DESC, [k].[RowID] ASC))
       |--Compute Scalar(DEFINE:([Expr1011]=If ([Expr1003]<[Expr1007]) then [Expr1003] else [Expr1007]-If ([Expr1003]-[d].[Qty]>[Expr1007]-[k].[Qty]) then ([Expr1003]-[d].[Qty]) else ([Expr1007]-[k].[Qty])))
            |--Hash Match(Inner Join, HASH:([TDebit].[RowID])=([d].[RowID]))
                 |--Index Scan(OBJECT:([tempdb].[dbo].[#ODebit] AS [TDebit]))
                 |--Filter(WHERE:(If ([Expr1003]<[Expr1007]) then [Expr1003] else [Expr1007]-If ([Expr1003]-[d].[Qty]>[Expr1007]-[k].[Qty]) then ([Expr1003]-[d].[Qty]) else ([Expr1007]-[k].[Qty])>0))
                      |--Compute Scalar(DEFINE:([Expr1003]=[Expr1003], [Expr1007]=[Expr1007]))
                           |--Nested Loops(Inner Join, OUTER REFERENCES:([d].[RowID], [d].[ItemID]))
                                |--Nested Loops(Inner Join, OUTER REFERENCES:([k].[RowID], [k].[ItemID]))
                                |    |--Hash Match(Inner Join, HASH:([k].[ItemID])=([d].[ItemID]), RESIDUAL:([k].[ItemID]=[d].[ItemID]))
                                |    |    |--Clustered Index Scan(OBJECT:([tempdb].[dbo].[#Okredit] AS [k]))
                                |    |    |--Clustered Index Scan(OBJECT:([tempdb].[dbo].[#ODebit] AS [d]))
                                |    |--Hash Match(Cache, HASH:([k].[RowID], [k].[ItemID]), RESIDUAL:([k].[RowID]=[k].[RowID] AND [k].[ItemID]=[k].[ItemID]))
                                |         |--Compute Scalar(DEFINE:([Expr1007]=If ([Expr1024]=0) then NULL else [Expr1025]))
                                |              |--Stream Aggregate(DEFINE:([Expr1024]=Count(*), [Expr1025]=SUM([k1].[Qty])))
                                |                   |--Index Spool(SEEK:([k1].[ItemID]=[k].[ItemID] AND [k1].[RowID] <= [k].[RowID]))
                                |                        |--Clustered Index Scan(OBJECT:([tempdb].[dbo].[#Okredit] AS [k1]))
                                |--Hash Match(Cache, HASH:([d].[RowID], [d].[ItemID]), RESIDUAL:([d].[RowID]=[d].[RowID] AND [d].[ItemID]=[d].[ItemID]))
                                     |--Compute Scalar(DEFINE:([Expr1003]=If ([Expr1026]=0) then NULL else [Expr1027]))
                                          |--Stream Aggregate(DEFINE:([Expr1026]=Count(*), [Expr1027]=SUM([d1].[Qty])))
                                               |--Index Spool(SEEK:([d1].[ItemID]=[d].[ItemID] AND [d1].[RowID] <= [d].[RowID]))
                                                    |--Clustered Index Scan(OBJECT:([tempdb].[dbo].[#ODebit] AS [d1]))
24 авг 05, 09:27    [1812206]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
пока выполняется вариант с табличными переменными, добавлю что время выполнения запроса со временными таблицами (план выше) составило 6 сек
24 авг 05, 09:31    [1812211]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
а вот план для табличных переменных (время выполнения 2 мин 11 сек):

SELECT FS.CreditDDID,      TDebit.DebitDDID,      FS.ItemID,      (    CASE WHEN QDebit1 < QKredit1 THEN QDebit1 ELSE QKredit1 END -       CASE WHEN QDebit1-QDebit > QKredit1-QKredit THEN QDebit1-QDebit ELSE QKredit1-QKredit END      ) AS Qty ,      @Stock
  |--Compute Scalar(DEFINE:([Expr1011]=If ([Expr1003]<[Expr1007]) then [Expr1003] else [Expr1007]-If ([Expr1003]-[d].[Qty]>[Expr1007]-[k].[Qty]) then ([Expr1003]-[d].[Qty]) else ([Expr1007]-[k].[Qty])))
       |--Nested Loops(Inner Join, OUTER REFERENCES:([d].[RowID]))
            |--Filter(WHERE:(If ([Expr1003]<[Expr1007]) then [Expr1003] else [Expr1007]-If ([Expr1003]-[d].[Qty]>[Expr1007]-[k].[Qty]) then ([Expr1003]-[d].[Qty]) else ([Expr1007]-[k].[Qty])>0))
            |    |--Compute Scalar(DEFINE:([Expr1003]=[Expr1003], [Expr1007]=[Expr1007]))
            |         |--Nested Loops(Inner Join, OUTER REFERENCES:([k].[RowID], [k].[ItemID]))
            |              |--Nested Loops(Inner Join, WHERE:([k].[ItemID]=[d].[ItemID]))
            |              |    |--Nested Loops(Inner Join, OUTER REFERENCES:([d].[RowID], [d].[ItemID]))
            |              |    |    |--Clustered Index Scan(OBJECT:(@ODebit AS [d]), ORDERED BACKWARD)
            |              |    |    |--Compute Scalar(DEFINE:([Expr1003]=If ([Expr1024]=0) then NULL else [Expr1025]))
            |              |    |         |--Stream Aggregate(DEFINE:([Expr1024]=Count(*), [Expr1025]=SUM([d1].[Qty])))
            |              |    |              |--Clustered Index Seek(OBJECT:(@ODebit AS [d1]), SEEK:([d1].[RowID] <= [d].[RowID]),  WHERE:([d].[ItemID]=[d1].[ItemID]) ORDERED FORWARD)
            |              |    |--Clustered Index Scan(OBJECT:(@Okredit AS [k]), ORDERED FORWARD)
            |              |--Hash Match(Cache, HASH:([k].[RowID], [k].[ItemID]), RESIDUAL:([k].[RowID]=[k].[RowID] AND [k].[ItemID]=[k].[ItemID]))
            |                   |--Compute Scalar(DEFINE:([Expr1007]=If ([Expr1026]=0) then NULL else [Expr1027]))
            |                        |--Stream Aggregate(DEFINE:([Expr1026]=Count(*), [Expr1027]=SUM([k1].[Qty])))
            |                             |--Clustered Index Seek(OBJECT:(@Okredit AS [k1]), SEEK:([k1].[RowID] <= [k].[RowID]),  WHERE:([k].[ItemID]=[k1].[ItemID]) ORDERED FORWARD)
            |--Clustered Index Seek(OBJECT:(@ODebit AS [TDebit]), SEEK:([TDebit].[RowID]=[d].[RowID]) ORDERED FORWARD)
24 авг 05, 09:35    [1812216]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
Aleks2
А ежели еще и коррелированные запросы убрать - вопще летать будет


А куда их денешь? Еще одну временную таблицу + UPDATE предлогаете?
24 авг 05, 09:38    [1812225]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
А можно увидеть результат вывода плана при
SET STATISTICS PROFILE ON 
GO
--здесь анализируемый скрипт
GO
SET STATISTICS PROFILE OFF
GO
?
24 авг 05, 09:45    [1812236]     Ответить | Цитировать Сообщить модератору
 Re: Скорость запросов из @TABLE и #TABLE  [new]
Easygoing
Member

Откуда: SPB.RU
Сообщений: 560
SELECT FS.CreditDDID,      TDebit.DebitDDID,      FS.ItemID,      (    CASE WHEN QDebit1 < QKredit1 THEN QDebit1 ELSE QKredit1 END -       CASE WHEN QDebit1-QDebit > QKredit1-QKredit THEN QDebit1-QDebit ELSE QKredit1-QKredit END      ) AS Qty ,      @Stock
  |--Compute Scalar(DEFINE:([Expr1011]=If ([Expr1003]<[Expr1007]) then [Expr1003] else [Expr1007]-If ([Expr1003]-[d].[Qty]>[Expr1007]-[k].[Qty]) then ([Expr1003]-[d].[Qty]) else ([Expr1007]-[k].[Qty])))
       |--Nested Loops(Inner Join, OUTER REFERENCES:([d].[RowID]))
            |--Filter(WHERE:(If ([Expr1003]<[Expr1007]) then [Expr1003] else [Expr1007]-If ([Expr1003]-[d].[Qty]>[Expr1007]-[k].[Qty]) then ([Expr1003]-[d].[Qty]) else ([Expr1007]-[k].[Qty])>0))
            |    |--Compute Scalar(DEFINE:([Expr1003]=[Expr1003], [Expr1007]=[Expr1007]))
            |         |--Nested Loops(Inner Join, OUTER REFERENCES:([k].[RowID], [k].[ItemID]))
            |              |--Nested Loops(Inner Join, WHERE:([k].[ItemID]=[d].[ItemID]))
            |              |    |--Nested Loops(Inner Join, OUTER REFERENCES:([d].[RowID], [d].[ItemID]))
            |              |    |    |--Clustered Index Scan(OBJECT:(@ODebit AS [d]), ORDERED BACKWARD)
            |              |    |    |--Compute Scalar(DEFINE:([Expr1003]=If ([Expr1024]=0) then NULL else [Expr1025]))
            |              |    |         |--Stream Aggregate(DEFINE:([Expr1024]=Count(*), [Expr1025]=SUM([d1].[Qty])))
            |              |    |              |--Clustered Index Seek(OBJECT:(@ODebit AS [d1]), SEEK:([d1].[RowID] <= [d].[RowID]),  WHERE:([d].[ItemID]=[d1].[ItemID]) ORDERED FORWARD)
            |              |    |--Clustered Index Scan(OBJECT:(@Okredit AS [k]), ORDERED FORWARD)
            |              |--Hash Match(Cache, HASH:([k].[RowID], [k].[ItemID]), RESIDUAL:([k].[RowID]=[k].[RowID] AND [k].[ItemID]=[k].[ItemID]))
            |                   |--Compute Scalar(DEFINE:([Expr1007]=If ([Expr1026]=0) then NULL else [Expr1027]))
            |                        |--Stream Aggregate(DEFINE:([Expr1026]=Count(*), [Expr1027]=SUM([k1].[Qty])))
            |                             |--Clustered Index Seek(OBJECT:(@Okredit AS [k1]), SEEK:([k1].[RowID] <= [k].[RowID]),  WHERE:([k].[ItemID]=[k1].[ItemID]) ORDERED FORWARD)
            |--Clustered Index Seek(OBJECT:(@ODebit AS [TDebit]), SEEK:([TDebit].[RowID]=[d].[RowID]) ORDERED FORWARD)

для переменной
24 авг 05, 09:51    [1812249]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить