查詢的同時運行，儘管有300倍之多行

我有兩個（幾乎）相同的查詢：查詢的同時運行，儘管有300倍之多行

;with cteMasterCreateExecAsXml as (
    SELECT guid, CAST(ExecutionOrder AS xml) as x 
    FROM (SELECT guid, ExecutionOrder 
      FROM @StrategiesToCreate sc 
      JOIN InFusion_Data.dbo.compare_FoxStrategy fs ON fs.Guid = sc.MasterGuid 
      WHERE fs.LinkedToTemplate = 0) k 
) -- selects ~45 rows 

SELECT MasterBIV.StrategyTagname, MasterBIV.Tagname, MasterBIV.Name, 
     b.blk.value('for $i in . return count(../*[. << $i]) + 1', 'int') as ExecOrder 
     INTO #MasterCreateExecOrder 
FROM cteMasterCreateExecAsXml 
CROSS APPLY x.nodes('//ExecutionOrder/Block') as b(blk) 
JOIN InFusion_Data.dbo.compare_BlockInfoView MasterBIV ON MasterBIV.BlockGuid = b.blk.value('@Id', 'uniqueidentifier')

而且

;with cteMasterExecAsXml as (
    SELECT guid, CAST(ExecutionOrder AS xml) as x 
    FROM (SELECT guid, ExecutionOrder FROM @StrategiesToCompare sc 
    JOIN InFusion_Data.dbo.compare_FoxStrategy fs ON fs.Guid = sc.MasterGuid) k 
) -- selects ~17000 rows 

SELECT MasterBIV.StrategyTagname, MasterBIV.Tagname, MasterBIV.Name, 
     b.blk.value('for $i in . return count(../*[. << $i]) + 1', 'int') as ExecOrder 
     INTO #MasterExecOrder 
FROM cteMasterExecAsXml 
CROSS APPLY x.nodes('//ExecutionOrder/Block') as b(blk) 
JOIN InFusion_Data.dbo.compare_BlockInfoView MasterBIV ON MasterBIV.BlockGuid = b.blk.value('@Id', 'uniqueidentifier')

根據SQL執行計劃，他們都採取相同的多少時間。第一個處理45行，第二個處理約17000行。這讓我覺得在兩個查詢中都有很多行被選中並轉換爲xml。

不幸的是，因爲我需要跨服務器執行查詢，所以我不能在模式中使用XML列。

任何想法這裏發生了什麼事情或我如何加快我的查詢？

來源

2017-03-27 Rory Anderson

執行計劃通常不顯示計時= P您可能意味着成本？是的，有一個鏈接，但沒有它不是一回事。您需要單獨運行和計算每個查詢，或者使用SQL Plan Explorer之類的東西來獲取有關如何運行的視圖，並且即使這樣您只能獲得整個查詢的計時，而不是構成整個操作的每個「部分」。另外，@ table-variables在有大量數據時非常糟糕（在這種情況下17k行很多）。而是使用＃temp-tables，因爲它們具有適當的統計處理並且還可以進行索引。優化器會很感激=） – deroby

使用臨時表做出了一個huuuuge的區別！現在查詢很快。還運行它作爲存儲過程幫助 –

正如我所見，diffence在「WHERE fs.LinkedToTemplate = 0」條件。

根據SQL執行計劃，它們都花費相同的時間。第一個處理45行，第二個處理約17000行。這讓我覺得在兩個查詢中都有很多行被選中並轉換爲xml。

它看起來像你的LinkedToTemplate列沒有表的索引，因此對於兩個詢問需要full table scan。因此要提高性能，您應該創建索引LinkedToTemplate列。

來源

2017-03-27 14:08:35

謝謝。碰巧我使用了錯誤的索引 - 我在StrategyName上設置了一個pk，應該使用它來代替guid。雖然我仍然不完全確定執行計劃發生了什麼，但我認爲在這種情況下並不完全準確 - 這不是一個緩慢的查詢，如果我將它從批處理中刪除，批處理仍然幾乎在同一時間運行。 –

查詢的同時運行，儘管有300倍之多行

回答

相關問題