sql >> Databasteknik >  >> RDS >> Sqlserver

SQL Server, den vilseledande XLOCK &optimeringar

Exklusivitet för X lås vs U låser

I låskompatibilitetsmatrisen nedan kan det ses att X lås är endast kompatibelt med schemastabilitet och Insert Range-Null-låstyper. U är kompatibel med följande ytterligare delade låstyper S /IS /RS-S /RI-S /RX-S

låskompatibilitetsmatris http://i.msdn.microsoft.com/ms186396.LockConflictTable(en-us,SQL.105).gif

Granularitet för X låser

Dessa tas ut bra på alla nivåer. Skriptet och profileringsspåret nedan visar att de har tagits ut på radnivå.

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

Men rader kan fortfarande läsas!

Det visar sig att vid read committed isoleringsnivå SQL Server tar inte alltid ut S låser, hoppar den över detta steg om det inte finns någon risk att läsa oengagerad data utan dem. Det betyder att det inte finns någon garanti för att en låskonflikt någonsin uppstår.

Men om det initiala valet är with (paglock,XLOCK)kommer stoppa lästransaktionen som X lås på sidan kommer att blockera IS sidlås som alltid kommer att behövas av läsaren. Detta kommer naturligtvis att påverka samtidigheten.

Andra varningar

Även om du låser raden/sidan betyder det inte att du blockerar all åtkomst till den raden i tabellen. Ett lås på en rad i det klustrade indexet kommer inte att förhindra att frågor läser data från motsvarande rad i ett täckande icke-klustrade index.



  1. Hur man tolkar PosgreSQL txid_current() värde

  2. De använda SELECT-satserna har ett annat antal kolumner (REDUX!!)

  3. Hur man formaterar datum och tid i MySQL

  4. Finns/finns inte:'välj 1' kontra 'välj fält'