Apakah ada perbedaan kinerja dalam melakukan dan mengembalikan transaksi read-only?

Saya membuka transaksi (baca berulang) ( BEGIN TRAN) untuk mengerjakan beberapa catatan tertentu. Hal pertama yang saya lakukan adalah memeriksa apakah data yang perlu saya ubah ada di database. Dalam beberapa kasus akan ada dan kemudian saya melanjutkan ke perubahan saya. Tetapi dalam beberapa kasus tidak ada yang bisa dilakukan. Dalam hal ini saya salah COMMIT TRANatau ROLLBACK TRANdan kembali dari prosedur yang tersimpan. Saat ini belum ada perubahan yang dilakukan pada data, sehingga efek komit dan kembalikan adalah sama.

Adakah pertimbangan yang harus saya perhatikan untuk memilih antara komit dan kembalikan? Apakah ada biaya kinerja yang berbeda? Pertimbangan lain?

Setelah menjalankan ini melalui sesi debugging (untuk menyegarkan kembali memori saya yang gagal):

• Rollback melakukan lebih banyak pemeriksaan daripada komitmen, tetapi seharusnya tidak menghasilkan pekerjaan tambahan atau memiliki pengaruh nyata pada kinerja dalam situasi yang Anda jelaskan.
• Transaksi baca-tulis tidak benar-benar dimulai kecuali dan sampai modifikasi data dilakukan.

Anda dapat melihat banyak dari ini menggunakan DMV, misalnya:

-- 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;

Menguji 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';

Keluaran:

Dari sudut pandang yang sepenuhnya praktis (seperti yang dicatat Aaron dalam komentar), mungkin lebih aman untuk mengeluarkan rollback untuk menjamin tidak ada perubahan yang dibuat, jika kode dimodifikasi di masa depan. Jadi, ini semua tentang niat: tidak ada perubahan = kembalikan.

Secara sepintas, REPEATABLE READadalah tingkat isolasi yang tidak biasa untuk dipilih; tidak selalu berfungsi seperti yang diharapkan orang secara intuitif . Tergantung pada kebutuhan Anda, Anda mungkin menemukan SNAPSHOTisolasi lebih cocok.