sql >> Database >  >> RDS >> Sqlserver

SQL Server, de misleidende XLOCK &optimalisaties

Exclusiviteit van X sloten vs U sloten

In de slotcompatibiliteitsmatrix hieronder is te zien dat de X lock is alleen compatibel met de vergrendelingstypen schemastabiliteit en Insert Range-Null. U is compatibel met de volgende aanvullende typen gedeelde vergrendelingen S /IS /RS-S /RI-S /RX-S

compatibiliteitsmatrix vergrendelen http://i.msdn.microsoft.com/ms186396.LockConflictTable(en-us,SQL.105).gif

granulariteit van X sloten

Deze worden er op alle niveaus prima uitgehaald. De script- en profiler-tracering hieronder laat zien dat ze succesvol zijn verwijderd op rijniveau.

CREATE TABLE test_table (id int identity(1,1) primary key, col char(40))

INSERT INTO test_table
SELECT NEWID() FROM sys.objects

select * from test_table with (rowlock,XLOCK) where id=10

Maar rijen kunnen nog steeds worden gelezen!

Het blijkt dat bij read committed isolatieniveau SQL Server haalt S niet altijd uit locks, slaat het deze stap over als er geen risico is om niet-vastgelegde gegevens zonder deze te lezen. Dit betekent dat er geen garantie is dat er ooit een slotconflict optreedt.

Als de eerste selectie echter with (paglock,XLOCK) . is dan zal stop de leestransactie als de X slot op de pagina blokkeert de IS paginavergrendeling die de lezer altijd nodig heeft. Dit heeft natuurlijk invloed op de gelijktijdigheid.

Andere waarschuwingen

Zelfs als u de rij/pagina vergrendelt, betekent dit niet dat u alle toegangen tot die rij in de tabel blokkeert. Een vergrendeling op een rij in de geclusterde index verhindert niet dat zoekopdrachten gegevens van de overeenkomstige rij in een dekkende niet-geclusterde index lezen.



  1. Spoolopdracht:voer geen SQL-instructie uit naar bestand

  2. JSON_QUERY() Voorbeelden in SQL Server (T-SQL)

  3. Hoe LOG10() werkt in MariaDB

  4. Expliciete JOINs vs Impliciete joins?