sql-server - 事务 block 会降低 SQL Server 的性能吗？

Question

现在我和一位同事正在争论非重要的 BEGIN TRAN....COMMIT TRAN block 的影响。我已经为简单的插入-更新-删除操作编写了大约 140 个存储过程，并且由于我们稍后可能需要在其中执行一些额外的操作，因此我已经包含了可能需要的 BEGIN TRAN 和 COMMIT TRAN block ，如下所示:

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

现在，许多此类交易可能永远都没有必要了。这些无关的 block 是否会显着影响性能？提前致谢。

Answer 1

还不足以引起注意。

也就是说，每个 TXN 将在 BEGIN TRAN 和 INSERT 之间打开一个额外的 OhNoSecond。如果有人能够测量它，我会印象深刻。

但是，如果您执行了 BEGIN TRAN 然后提示用户输入，那么您的腿就需要断了...

但好主意:我这样做是为了让我的所有写入过程都 100% 一致，具有相同的错误处理，可以嵌套等

编辑:在 Remus 回答后，我发现我没有链接到我的嵌套 TXN 模板:Nested stored procedures containing TRY CATCH ROLLBACK pattern?这与 Remus 的不同之处在于它总是回滚并且没有保存点

编辑，快速而肮脏的测试表明，交易速度加快了大约 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

颠倒更新顺序保持相同的行为