Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why better isolation level means better performance in SQL Server

When measuring performance on my query I came up with a dependency between isolation level and elapsed time that was surprising to me

READUNCOMMITTED - 409024
READCOMMITTED - 368021
REPEATABLEREAD - 358019
SERIALIZABLE - 348019

Left column is table hint, and the right column is elapsed time in microseconds (sys.dm_exec_query_stats.total_elapsed_time). Why better isolation level gives better performance? This is a development machine and no concurrency whatsoever happens. I would expect READUNCOMMITTED to be the fasted due to less locking overhead.

Update: I did measure this with

DBCC DROPCLEANBUFFERS 
DBCC FREEPROCCACHE  

issued and Profiler confirms there're no cache hits happening.

like image 982
Oleg Zhylin Avatar asked Mar 15 '10 22:03

Oleg Zhylin


People also ask

What is the purpose of isolation levels in SQL?

Isolation levels are described for which concurrency side effects are allowed, such as dirty reads or phantom reads. Transaction isolation levels control the following effects: Whether locks are taken when data is read, and what type of locks are requested.

Which isolation level is best in SQL Server?

Serializable. This is the highest isolation level and prevents all possible types of concurrency phenomena in SQL Server, but on the other hand, the serializable level decreases performance and increases the likelihood of deadlocks.

What are the advantages of using isolated DB?

If the application developer is able to ensure the correctness of their code when no other concurrent processes are running, a system that guarantees perfect isolation will ensure that the code remains correct even when there is other code running concurrently in the system that may read or write the same data.


1 Answers

First of all, you need to run the query repeatedly under each isolation level and average the result, discarding the one with the maximum time. This will eliminate the buffer warm up impact: you want all runs to be on a warm cache, not have one query warm the cache and pay the penalty in comparison.

Next, you need to make sure you measure under realistic concurrency scenario. IF you will have updates/inserts/deletes occur under real life, then you must add them to your test, since they will impact tremendously the reads under various isolation level. The last thing you want is to conclude 'serializable reads are fastest, lets use them everywhere' and then watch the system melt down in production because everything is serialized.

Other than that, the only isolation level that is legitimately faster is dirty reads, since it doesn't acquire locks. Read committed snapshot (which you did not measure) also doesn't acquire locks, but it does impact performance overall due to row versioning overhead.

like image 151
Remus Rusanu Avatar answered Sep 27 '22 19:09

Remus Rusanu