Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

SQL Server, le trompeur XLOCK &optimisations

Exclusivité de X serrures vs U serrures

Dans la matrice de compatibilité des serrures ci-dessous, on peut voir que le X lock n'est compatible qu'avec les types de verrouillage de stabilité de schéma et Insert Range-Null. U est compatible avec les types de verrous partagés supplémentaires suivants S /IS /RS-S /RI-S /RX-S

matrice de compatibilité de verrouillage http://i.msdn.microsoft.com/ms186396.LockConflictTable(fr-fr,SQL.105).gif

Granularité de X serrures

Ceux-ci sont bien sortis à tous les niveaux. La trace du script et du profileur ci-dessous montre qu'ils ont été supprimés avec succès au niveau de la ligne.

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

Mais les lignes peuvent toujours être lues !

Il s'avère qu'à read committed niveau d'isolement SQL Server ne supprimera pas toujours S locks, il ignorera cette étape s'il n'y a aucun risque de lire des données non validées sans eux. Cela signifie qu'il n'y a aucune garantie qu'un conflit de verrouillage se produise.

Cependant si la sélection initiale est with (paglock,XLOCK) alors cela va arrêter la transaction de lecture comme le X verrouiller la page bloquera le IS verrou de page qui sera toujours nécessaire au lecteur. Cela aura bien sûr un impact sur la simultanéité.

Autres mises en garde

Même si vous verrouillez la ligne/page, cela ne signifie pas que vous bloquez tous les accès à cette ligne dans le tableau. Un verrou sur une ligne de l'index clusterisé n'empêchera pas les requêtes de lire les données de la ligne correspondante dans un index non clusterisé couvrant.