sql >> Databáze >  >> RDS >> Sqlserver

TABLOCK vs TABLOCKX

Velký rozdíl, TABLOCK se pokusí chytit "sdílené" zámky a TABLOCKX exkluzivní zámky.

Pokud jste v transakci a uchopíte exkluzivní zámek na stole, EG:

SELECT 1 FROM TABLE WITH (TABLOCKX)

Žádné další procesy nebudou moci zachytit žádné zámky na stole, což znamená vše dotazy pokoušející se hovořit s tabulkou budou zablokovány, dokud nebude transakce potvrzena.

TABLOCK pouze uchopí sdílený zámek, sdílené zámky se uvolní po provedení příkazu, pokud je izolace vaší transakce READ COMMITTED (výchozí). Pokud je vaše úroveň izolace vyšší, například:SERIALIZABLE , sdílené zámky jsou drženy až do konce transakce.

Sdílené zámky jsou, hmmm, sdílené. To znamená, že 2 transakce mohou číst data z tabulky současně, pokud obě mají na stole zámek S nebo IS (přes TABLOCK ). Pokud však transaction A drží sdílený zámek na stole, transaction B nebude moci získat exkluzivní zámek, dokud nebudou uvolněny všechny sdílené zámky. Přečtěte si o tom, které zámky jsou kompatibilní se kterými, na msdn.

Oba tipy způsobí, že db obejde použití podrobnějších zámků (jako jsou zámky na úrovni řádku nebo stránky). V zásadě vám granulárnější zámky umožňují lepší souběžnost. Jedna transakce tedy může například aktualizovat řádek 100 ve vaší tabulce a další řádek 1000 současně ze dvou transakcí (se zámky stránek je to složitější, ale to přeskočte).

Obecně je to, co chcete, granulární zámky, ale někdy můžete chtít snížit souběžnost db, abyste zvýšili výkon konkrétní operace a eliminovali možnost uváznutí.

Obecně byste nepoužili TABLOCK nebo TABLOCKX pokud jste to nezbytně potřebovali pro nějaký okrajový případ.



  1. java.lang.IllegalStateException:Nelze přečíst řádek 0, sloupec -1 z CursorWindow – problém Android sqlite

  2. Oracle:jak UPSERT (aktualizovat nebo vložit do tabulky?)

  3. Jak přidat zdroj dat PostgreSQL do WildFly 9.0?

  4. Odstranění dotazu Oracle trvá příliš dlouho