事務塊是否會降低SQL Server的性能？

現在我和一位同事爭論非重要的BEGIN TRAN .... COMMIT TRAN塊的影響。我已經寫了大約140個存儲過程用於簡單的插入 - 更新 - 刪除操作，因爲我們可能以後需要在它們中做一些額外的操作，所以我已經包含了可能必需的BEGIN TRAN和COMMIT TRAN塊：事務塊是否會降低SQL Server的性能？

CREATE PROCEDURE [Users].[Login_Insert] 

     @Username   nvarchar (50) OUTPUT, 
     @Password   char (40), 
     @FullName   nvarchar (150), 
     @LoginTypeId  int 

AS 

SET NOCOUNT ON; 

BEGIN TRY 
BEGIN TRAN 

INSERT [Users].[Login] 
(
     [Username], 
     [Password], 
     [FullName], 
     [LoginTypeId] 
) 
VALUES 
(
     @Username, 
     @Password, 
     @FullName, 
     @LoginTypeId 
) 

COMMIT TRAN 
RETURN 1 
END TRY 

BEGIN CATCH 
ROLLBACK TRAN 

RETURN -1 
END CATCH 

GO

現在很多這些交易可能永遠不需要。這些無關塊是否會以顯着的方式影響性能？在此先感謝。

來源

2011-06-13 M2X

不足以注意。

也就是說，每個TXN將在BEGIN TRAN和INSERT之間開放一個額外的OhNoSecond。如果有人能夠衡量它，我會留下深刻的印象。

但是，如果你做了BEGIN TRAN然後提示用戶輸入，你的腿斷需要...

很好，儘管我這樣做，所以我所有的寫特效是100％一致，具有相同的錯誤處理，可以嵌套等

編輯：瑞摩斯之後的回答，我看我沒有鏈接到我的窩TXN模板：Nested stored procedures containing TRY CATCH ROLLBACK pattern?這是萊姆斯不同的，因爲它總是回滾，也沒有保存點

編輯，一項快速而骯髒的測試顯示，在交易時間約2/3的情況下，它更快速。

SET NOCOUNT ON 
SET STATISTICS IO OFF 

DECLARE @date DATETIME2 
DECLARE @noTran INT 
DECLARE @withTran INT 

SET @noTran = 0 
SET @withTran = 0 

DECLARE @t TABLE (ColA INT) 
INSERT @t VALUES (1) 

DECLARE 
    @count INT, 
    @value INT 

SET @count = 1 

WHILE @count < 100 
BEGIN 

    SET @date = GETDATE() 
    UPDATE smalltable SET smalltablename = CASE smalltablename WHEN 'test1' THEN 'test' ELSE 'test2' END WHERE smalltableid = 1 
    SET @noTran = @noTran + DATEDIFF(MICROSECOND, @date, GETDATE()) 

    SET @date = GETDATE() 
    BEGIN TRAN 
    UPDATE smalltable SET smalltablename = CASE smalltablename WHEN 'test1' THEN 'test' ELSE 'test2' END WHERE smalltableid = 1 
    COMMIT TRAN 
    SET @withTran = @withTran + DATEDIFF(MICROSECOND, @date, GETDATE()) 

    SET @count = @count + 1 
END 

SELECT 
    @noTran/1000000. AS Seconds_NoTransaction, 
    @withTran/1000000. AS Seconds_WithTransaction 

Seconds_NoTransaction Seconds_WithTransaction 
2.63200000    2.70400000 
2.16700000    2.12300000

逆轉更新的順序保持相同的行爲

來源

2011-06-13 19:00:33 gbn

我試着測量一次，不能。沒有可衡量的影響。 – 2011-06-13 19:02:46

希望我的同事能夠看到這個結論。非常感謝朋友 – M2X 2011-06-13 19:02:58

[答案在這裏說，它是可衡量的]（http://stackoverflow.com/questions/3201982/having-transaction-in-all-queries/3273661#3273661） – 2011-06-14 05:59:31

在您發佈不會有明顯的影響的代碼，但交易確實有對性能的影響，他們可以顯着改善因性能登錄提交刷新分組或者由於錯誤管理的爭用問題，他們可能會顯着降低性能。但底線是當交易需要正確性時，您不能跳過。話雖如此，但您的模板對於交易和try-catch塊來說確實相當糟糕。 catch塊中的transcation必須具有返回值（-1,0,1）的三態邏輯檢查XACT_STATE並正確處理註定事務。例如，請參閱Exception handling and nested transactions。

此外，你永遠不應該混用try-catch錯誤處理和返回碼錯誤處理。挑一個並堅持下去，最好試試。換句話說，你的存儲過程應該是RAISE，而不是返回-1。將異常與錯誤代碼混合在一起會使您的代碼成爲噩夢來維護和正確調用。

來源

2011-06-13 19:27:21

，您的其他鏈接速度會更快。我真的很高興您提到它。謝謝你的repsonse – M2X 2011-06-13 20:30:25

事務塊是否會降低SQL Server的性能？

回答

相關問題