如何避免在 SQL Server 中盲目地追求一句處理

SELECT NULL, SUM(a), SUM(b) FROM @t

性能測試結果 id  a       b --- ------- ------- 1   3410   2063 2   1703   1656 3   1763   1656 4   1800   1793 5   1643   1856

NULL   10319  9024

從結果看，兩者的性能差異很小，所以兩者從性能上比較，可以視為沒有差異

問題所在

雖然在性能上，兩者沒有什么差異，但另一個問題也許你從來沒有考慮過，那就是對表的訪問的問題，在方法A中，肯定只會訪問到一個表；而在方法B中，情況還是如此嗎？答案是否定的，方法B始終會掃描兩個表。而這樣的潛臺詞是，即使在我的查詢中，只會用到A表，但如果B表被下了鎖的話，整個查詢就會被阻塞，而方法A不會。

為了證明這個問題，我們再做下面的測試

BLOCK 的測試—為表A加鎖 (查詢窗口A) BEGIN TRAN     UPDATE A SET [ITEM] = RIGHT(NEWID(), 4)     WHERE [ITEM] BETWEEN '9' AND 'A' --ROLLBACK TRAN  -- 不回滾事務，讓鎖一直保持

BLOCK 的測試—測試查詢方法A(查詢窗口B) -- run query windows 2 DECLARE @a int SET @a = 1   IF @a = 0     SELECT [TranNumber] FROM A     WHERE [ITEM] < 'A' ELSE IF @a = 1     SELECT [ItemNumber] FROM B     WHERE [ItemNumber] < 'A'

BLOCK 的測試—測試查詢方法B(查詢窗口C) -- run query windows 3 DECLARE @a int SET @a = 1   SELECT [ITEM] FROM A WHERE @a = 0     AND [ITEM] < 'A' UNION ALL SELECT [ItemNumber] FROM B WHERE @a = 1     AND [ItemNumber] < 'A'  

結果

你會看到，查詢窗口B中的查詢會及時地完成，而查詢窗口C的查詢會一直等待，你可以通過執行存儲過程 sp_who2，查看當前的BLOCK狀況來確定查詢窗口C的查詢是否被查詢窗口A的查詢BLOCK住  

結論

不要使用查詢方法B，它看起來很棒，實際的結果即是會增加被BLOCK的機會

文章來源于領測軟件測試網 http://www.kjueaiud.com/