Expliquer les connaissances pertinentes sur le verrouillage de mise à jour (U) et le verrouillage exclusif (X)

Je n'ai jamais sérieusement compris le verrouillage de l'opération UPDATE j'en ai vu récemment sur le forum MSDN . Question, posant des questions sur le problème de blocage de la mise à jour des tables de tas. La question est très simple. Il existe des tables et des données similaires à celle-ci :

CREATE TABLE dbo.tb(
     c1 int,
     c2 char(10),
     c3 varchar(10)
);
GO
DECLARE @id int;
SET @id = 0;
WHILE @id <5
BEGIN;
     SET @id = @id + 1;
     INSERT dbo.tb VALUES( @id, &#39;b&#39; + RIGHT(10000 + @id, 4), &#39;c&#39; + RIGHT(100000 + @id, 4) );
END;

Effectuer une opération de mise à jour dans la première requête :

BEGIN TRAN
UPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 2;
WAITFOR DELAY '00:00:30';
UPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 5;
ROLLBACK;

Dans la première requête Immédiatement après le début de l'exécution, effectuez les opérations suivantes dans la deuxième requête

BEGIN TRAN
UPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 1;
ROLLBACK;

Pourquoi le décès se produit-il ? lock, si la condition est changée en c1 = 4, il n'y aura pas de blocage.

Au début, je pensais que c'était relativement simple. La performance du blocage est de former une boucle d'attente (pour deux requêtes, cela peut simplement être pensé). comme s'attendre l'un l'autre) La libération des ressources verrouillées de l'autre partie).

Pour cet exemple, la première requête est mise à jour deux fois. Elle mettra d'abord à jour et verrouillera un enregistrement, puis attendra la deuxième mise à jour mais la seconde Chaque ; la requête ne mettra à jour qu'un seul enregistrement. Soit elle entre en conflit avec la première requête et ne peut pas obtenir le verrou, et doit attendre la fin de la requête à ce moment-là, ou elle peut obtenir le verrou et terminer la mise à jour ; . Il semble qu’une impasse ne devrait pas se produire. L’impasse pourrait-elle être causée par d’autres raisons ?

Je l'ai simplement testé sur mon ordinateur et il semble qu'il n'y ait effectivement pas de blocage.

Mais plus tard, j'ai découvert grâce au suivi de profil de la situation de verrouillage de l'opération de mise à jour que mon analyse était complètement fausse. La raison principale est qu’il n’existe pas de compréhension correcte de la manière dont les verrous sont utilisés dans les opérations de mise à jour.

Sur l'aide en ligne "Mode verrouillage" Il y a des instructions sur la mise à jour de U (verrouillage de mise à jour) et /library/ms175519(v=sql.105).aspx

Mais c'est vraiment vague. Verrou S, ce que j'ai toujours pensé. Le verrou S est utilisé dans le processus d'interrogation des données (le même que SELECT. Après avoir trouvé les enregistrements qui remplissent les conditions, le verrou U est utilisé, puis converti en verrou X). pour la mise à jour. Les résultats du suivi de

Profil (profil) m'indiquent qu'il s'agit d'une mauvaise compréhension. Créez un nouveau suivi dans le profil et sélectionnez . Verrouillage :Acquis(Verrouillage), Verrouillage :Acquis (Libérer le verrou ) Résolvez les deux événements et définissez le filtre pour suivre uniquement le spid correspondant à la fenêtre de requête à des fins de test (vous pouvez exécuter PRINT @@SPID obtenu), puis exécutez une instruction de mise à jour, telle que UPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 3

Comme vous pouvez le voir dans Profil, U est ajouté à chaque enregistrement. L'opération de verrouillage libérera immédiatement les verrous U pour les enregistrements qui ne remplissent pas les conditions ; pour les enregistrements qui remplissent les conditions, ils seront éventuellement convertis en verrous X. Comme indiqué ci-dessous.

Notez que dans ce résultat de suivi À l'intérieur , il n'y a pas de verrou S.

De plus, j'ai fait quelques tests :

1. En augmentant le nombre d'enregistrements pour les tests de mise à jour, vous constaterez que les enregistrements impliqués dans l'analyse des données ont des verrous U et ne sont pas limités à la page où se trouve l'enregistrement de mise à jour. Cela montre d'un autre point de vue que le Scan est terrible dans les grandes montres.

2. Lors de l'utilisation de l'analyse d'index, il sera également constaté grâce au suivi que la ressource d'index analysée possède un verrou U. Si la mise à jour n'implique pas de modifications d'index, elle est détectée. sera seulement L'enregistrement correspondant a un verrou U à X, et le verrou U de l'index sera libéré s'il affecte l'index, le verrou U de l'index sera converti en verrou X ;

3. L'opération de suppression est similaire à l'opération de mise à jour

4. Utiliser MISE À JOUR aSET c2 = 'xx' FROM dbo.tb AS a AVEC(NOLOCK) OÙ c1 = 3 La situation de verrouillage de est la même, et U ou >

   Enfin, revenons sur le problème de blocage dans l'exemple :

Pour la première requête, la première mise à jour analyse tous les enregistrements de la table dans l'ordre, pour chaque enregistrement, ajoutez un verrou U pour déterminer s'il répond aux conditions de mise à jour. il remplit les conditions, convertissez-le en verrou X ; s'il ne remplit pas les conditions, libérez le verrou U ; Lorsque la première mise à jour est terminée, la première requête verrouille un enregistrement (le verrou est conservé car la transaction n'est pas terminée), puis attend la deuxième mise à jour

• Pour la deuxième requête, chaque enregistrement de la table est analysé à tour de rôle (comme pour la mise à jour précédente). Si l'enregistrement qu'il met à jour est analysé avant l'enregistrement mis à jour par la première requête, cet enregistrement deviendra également un verrou X lors de la poursuite et lorsque. atteignant le point zéro de l'enregistrement de verrouillage X de la première requête, U entre en conflit avec La deuxième mise à jour commence à s'exécuter et chaque enregistrement est analysé à tour de rôle. Il n'y aura pas de conflit au sein de la même transaction, il n'y aura donc pas de conflit avec l'enregistrement qu'il avait précédemment. verrouillé Cependant, lorsqu'il s'agit d'interroger le deuxième enregistrement verrouillé, il ne peut pas obtenir le verrou U, il doit attendre la deuxième requête pour libérer la ressource. A ce moment, une attente mutuelle se forme, qui remplit la condition d'impasse

• Si l'enregistrement qui doit être mis à jour dans la requête deux est après le premier enregistrement mis à jour dans interrogez un, alors ce ne sera pas le cas. Il y aura un blocage car la requête deux attendra en raison d'un conflit de verrouillage lorsqu'elle analysera le premier enregistrement mis à jour de la requête 1. À ce stade, elle ne définit aucun verrou sur aucun enregistrement en conflit avec l'enregistrement. fonctionnement de la première requête. Ce fut le cas lorsque je l'ai testé moi-même sans blocage.

• Notez que l'ordre mentionné ici est l'ordre dans lequel les données sont lues, qui n'est pas nécessairement le même que l'ordre de stockage. L'ordre des enregistrements sur le disque n'est pas nécessairement le même. comme l'ordre des enregistrements INSERT. C'est aussi la raison pour laquelle je n'ai pas testé les blocages dans les mêmes conditions (dans mon environnement, l'ordre de lecture se trouve être différent de l'ordre d'INSERT)

Lors de la mise à jour, enregistrez l'ordre de lecture, qui peut être suivi via le profilVerrouillage :Acquis (Verrouillage)En termes d'événements, lorsqu'une grande quantité de données est impliquée, il y aura des lectures simultanées si le serveur le prend en charge. C'est également un facteur à prendre en compte lors de l'analyse des blocages

Cet article explique Explique les connaissances pertinentes sur le verrouillage de mise à jour (U) et le verrouillage exclusif (X), plus Pour le contenu connexe, veuillez prêter attention au site Web chinois php.

Recommandations associées :

Améliorations de SQL Server 2008 dans la gestion des conversions de types de données implicites dans les plans d'exécution

Comment implémenter une requête de relation parent-enfant de niveau infini en une seule phrase dans MySQL

Comment accéder à SQL Server FileStream avec progression



Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!