Existe uma diferença de desempenho ao confirmar e reverter uma transação somente leitura?

Abro uma transação (leitura repetível) ( BEGIN TRAN) para fazer algum trabalho em determinados registros. A primeira coisa que faço é verificar se os dados que preciso alterar estão no banco de dados. Em alguns casos, haverá e continuarei com minhas alterações. Mas, em alguns casos, não haverá nada a fazer. Nesse caso, eu COMMIT TRANou ROLLBACK TRANretorno do procedimento armazenado. No momento, ainda não foram feitas alterações nos dados; portanto, o efeito de confirmação e reversão é o mesmo.

Há alguma consideração que eu deveria estar ciente de escolher entre confirmar e reverter? Existe custo de desempenho diferente? Outras considerações?

Após executar isso por meio de uma sessão de depuração (para atualizar minha memória com falha):

• A reversão faz mais verificações do que uma confirmação, mas não deve resultar em trabalho adicional ou ter um efeito perceptível no desempenho na situação que você descreve.
• A transação de leitura e gravação não começa verdadeiramente, a menos e até que uma modificação de dados seja feita.

Você pode ver muito disso usando DMVs, por exemplo:

-- Temporary procedure to show the state of the transaction
CREATE PROCEDURE #TranState
    @Comment varchar(100)
AS
BEGIN
    SELECT 
        @Comment AS Comment,
        DTCT.transaction_id,
        database_name =
            CASE DTDT.database_id
                WHEN 32767 THEN N'resource'
                ELSE DB_NAME(DTDT.database_id)
            END,
        tran_begin_time = DTDT.database_transaction_begin_time,
        tran_type =
            CASE DTDT.database_transaction_type
                WHEN 1 THEN 'read/write'
                WHEN 2 THEN 'read only'
                WHEN 3 THEN 'system'
            END,
        tran_state =
            CASE DTDT.database_transaction_state
                WHEN 1 THEN 'The transaction has not been initialized.'
                WHEN 3 THEN 'The transaction has been initialized but has not generated any log records.'
                WHEN 4 THEN 'The transaction has generated log records.'
                WHEN 5 THEN ' The transaction has been prepared.'
                WHEN 10 THEN 'The transaction has been committed.'
                WHEN 11 THEN 'The transaction has been rolled back.'
                WHEN 12 THEN 'The transaction is being committed. In this state the log record is being generated, but it has not been materialized or persisted.'
            END
    FROM sys.dm_tran_current_transaction AS DTCT
    JOIN sys.dm_tran_database_transactions AS DTDT
        ON DTDT.transaction_id = DTCT.transaction_id;
END;

Testando no AdventureWorks:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

BEGIN TRANSACTION;

EXECUTE dbo.#TranState @Comment = 'After Begin Tran';

SELECT TOP (1)
    P.Name
FROM Production.Product AS P
ORDER BY 
    P.Name;

EXECUTE dbo.#TranState @Comment = 'After Select';

UPDATE Production.Product
SET Name = N'New Blade'
WHERE Name = N'Blade';

EXECUTE dbo.#TranState @Comment = 'After Update';

-- Or Commit
ROLLBACK TRANSACTION;

EXECUTE dbo.#TranState @Comment = 'After Tran';

Resultado:

Do ponto de vista puramente prático (como Aaron observou em um comentário), provavelmente é mais seguro emitir uma reversão para garantir que nenhuma alteração seja feita, caso o código seja modificado no futuro. Portanto, trata-se de intenção: sem alterações = reversão.

De passagem, REPEATABLE READé um nível de isolamento incomum para escolher; nem sempre funciona como as pessoas esperariam intuitivamente . Dependendo dos seus requisitos, você pode achar que o SNAPSHOTisolamento é um ajuste melhor.