Verrouillage optimisé

S’applique à : SQL Server 2025 (17.x) Azure SQL Database Azure SQL Managed Instance Base de données SQL dans Microsoft Fabric

Le verrouillage optimisé offre un mécanisme de verrouillage des transactions amélioré pour réduire le blocage des verrous et la consommation de mémoire de verrou pour les transactions simultanées.

Qu’est-ce que le verrouillage optimisé ?

Le verrouillage optimisé permet de réduire la mémoire des verrous, car très peu de verrous sont conservés, même pour les grandes transactions. En outre, le verrouillage optimisé évite les escalades de verrous et peut éviter certains types d’interblocages. Cela autorise davantage d’accès simultanés à la table.

Le verrouillage optimisé se compose de deux composants principaux : le verrouillage d’ID de transaction (TID) et le verrou après qualification (LAQ).

Un ID de transaction (TID) est un identificateur unique d’une transaction. Chaque ligne est étiquetée avec le dernier TID qui l’a modifié. Au lieu d'avoir potentiellement de nombreux verrous sur les identificateurs de clé ou de ligne, un seul verrou sur la TID est utilisé pour protéger toutes les lignes modifiées. Pour plus d'informations, consultez Verrouillage d'ID de transaction (TID).
Le verrou après qualification (LAQ) est une optimisation qui évalue les prédicats de requête en utilisant la dernière version validée de la ligne sans acquérir de verrou, ce qui améliore l’accès concurrentiel. LAQ nécessite l’isolation des captures instantanées validées en lecture (RCSI). Pour plus d’informations, consultez verrou après qualification (LAQ).

Par exemple:

Sans verrouillage optimisé, la mise à jour de 1 000 lignes dans une table peut nécessiter 1 000 verrous de ligne exclusifs (X) conservés jusqu’à la fin de la transaction.
Avec le verrouillage optimisé, la mise à jour de 1 000 lignes dans une table peut nécessiter 1 000 X verrous de ligne, mais chaque verrou est libéré dès que chaque ligne est mise à jour et qu’un X seul verrou TID est conservé jusqu’à la fin de la transaction. Comme les verrous sont libérés rapidement, l’utilisation de la mémoire des verrous est réduite et l’escalade de verrous est beaucoup moins susceptible de se produire, ce qui améliore l’accès concurrentiel de la charge de travail.

Note

L’activation du verrouillage optimisé réduit ou élimine les verrous de ligne et de page acquis par les instructions DML (Data Modification Language) telles que INSERT, UPDATE, DELETE, MERGE. Il n’a aucun effet sur d’autres types de verrous de base de données et d’objets, tels que les verrous de schéma.

Availability

Le tableau suivant récapitule la disponibilité et l’état activé du verrouillage optimisé sur les plateformes SQL.

Platform	Available	Activé par défaut
Azure SQL Database	Yes	Oui (toujours activé)
Base de données SQL dans Microsoft Fabric	Yes	Oui (toujours activé)
Azure SQL Managed Instance^AUTD	Yes	Oui (toujours activé)
Azure SQL Managed Instance²⁰²⁵	Yes	Oui (toujours activé)
Azure SQL Managed Instance²⁰²²	No	N/A
SQL Server 2025 (17.x)	Yes	Non (peut être activé par base de données)
SQL Server 2022 (16.x) et versions antérieures	No	N/A

Activer et désactiver

Pour activer ou désactiver le verrouillage optimisé pour une base de données SQL Server, utilisez la ALTER DATABASE ... SET OPTIMIZED_LOCKING = ON | OFF commande. Pour plus d'informations, consultez ALTER DATABASE SET options.

Le verrouillage optimisé s’appuie sur d’autres fonctionnalités de la base de données :

Vous devez activer la récupération de base de données accélérée (ADR) sur une base de données avant de pouvoir activer le verrouillage optimisé. À l’inverse, pour désactiver ADR, vous devez d’abord désactiver le verrouillage optimisé s’il est activé.
Pour tirer le meilleur parti du verrouillage optimisé, l’isolement de capture instantanée à lecture validée (RCSI) doit être activé pour la base de données. Le composant LAQ du verrouillage optimisé est en vigueur uniquement si le mode RCSI est activé.

ADR est toujours activé dans Azure SQL Database, Azure SQL Managed Instance et SQL Database dans Microsoft Fabric. RCSI est activé par défaut dans Azure SQL Database et SQL Database dans Microsoft Fabric.

Pour vérifier que ces options sont activées pour votre base de données actuelle, connectez-vous à la base de données et exécutez la requête T-SQL suivante :

SELECT database_id,
       name,
       is_accelerated_database_recovery_on,
       is_read_committed_snapshot_on,
       is_optimized_locking_on
FROM sys.databases
WHERE name = DB_NAME();

Le verrouillage optimisé est-il activé ?

Le verrouillage optimisé est activé par base de données. Connectez-vous à votre base de données, puis utilisez la requête suivante pour vérifier si le verrouillage optimisé est activé :

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsOptimizedLockingOn') AS is_optimized_locking_enabled;

Result	Description
`0`	Le verrouillage optimisé est désactivé.
`1`	Le verrouillage optimisé est activé.
`NULL`	Le verrouillage optimisé n’est pas disponible.

Vous pouvez également utiliser la vue catalogue sys.databases . Par exemple, pour voir si le verrouillage optimisé est activé pour toutes les bases de données, exécutez la requête suivante :

SELECT database_id,
       name,
       is_optimized_locking_on
FROM sys.databases;

Vue d’ensemble du verrouillage

Il s’agit d’un bref résumé du comportement lorsque le verrouillage optimisé n’est pas activé. Pour plus d’informations, consultez le Guide du verrouillage des transactions et du contrôle de version de ligne.

Dans le moteur de base de données, le verrouillage est un mécanisme qui empêche plusieurs transactions de mettre à jour simultanément les mêmes données afin de garantir les propriétés ACID des transactions.

Lorsqu’une transaction doit modifier des données, elle peut demander un verrou sur les données. Le verrou est attribué si aucun autre verrou en conflit n’est conservé sur les données, et la transaction peut poursuivre la modification. Si un autre verrou en conflit est conservé sur les données, la transaction doit attendre sa libération avant de pouvoir continuer.

Lorsque plusieurs transactions tentent d’accéder simultanément aux mêmes données, le moteur de base de données doit résoudre des conflits potentiellement complexes avec des lectures et des écritures simultanées. Le verrouillage est l’un des mécanismes par lesquels le moteur peut fournir la sémantique des niveaux d’isolement des transactions ANSI SQL. Bien que le verrouillage dans les bases de données soit essentiel, la concurrence réduite, les interblocages, la complexité et le traitement de verrou peuvent affecter les performances et la scalabilité.

Verrouillage de l’ID de transaction (TID)

Lorsque des niveaux d'isolement basés sur le contrôle de version de ligne sont utilisés ou lorsque l'ADR est activé, chaque ligne de la base de données contient en interne un ID de transaction (TID). TID est conservé avec la ligne. Chaque transaction modifiant une ligne marque la ligne avec son TID.

Avec le verrouillage TID, au lieu de prendre le verrou sur la clé de la ligne, le verrou est pris sur le TID de la ligne. La transaction de modification contient un verrou X sur son TID. D’autres transactions obtiennent un verrou S sur le TID en attendant la fin de la première transaction. Avec le verrouillage TID, les verrous de page et de ligne continuent d'être pris pour les modifications, mais dès qu'une ligne est modifiée, chaque page et verrou de ligne est libéré. Le seul verrou conservé jusqu’à la fin de la transaction est le verrou X unique sur la ressource TID, qui remplace les verrous (clés) de page et de ligne.

Examinons l’exemple suivant qui montre les verrous de la session en cours pendant qu’une transaction d’écriture est active :

/* Is optimized locking is enabled? */
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsOptimizedLockingOn') AS is_optimized_locking_enabled;

CREATE TABLE t0
(
a int PRIMARY KEY,
b int NULL
);

INSERT INTO t0 VALUES (1,10),(2,20),(3,30);
GO

BEGIN TRANSACTION;

UPDATE t0
SET b = b + 10;

SELECT *
FROM sys.dm_tran_locks
WHERE request_session_id = @@SPID
      AND
      resource_type IN ('PAGE','RID','KEY','XACT');

COMMIT TRANSACTION;
GO

DROP TABLE IF EXISTS t0;

Si le verrouillage optimisé est activé, la requête ne contient qu’un seul verrou X sur la ressource XACT (transaction).

Si le verrouillage optimisé n’est pas activé, la même requête contient quatre verrous : un verrou IX (exclusif de l’intention) sur la page contenant les lignes, et trois verrous de clé X sur chaque ligne :

L’sys.dm_tran_locks vue de gestion dynamique (DMV) est utile pour examiner ou résoudre les problèmes de verrouillage. Ici, il est utilisé pour observer le verrouillage optimisé en action.

Verrou après qualification (LAQ)

En s’appuyant sur l’infrastructure TID, le composant LAQ du verrouillage optimisé change la façon dont les instructions DML telles que INSERT, UPDATEet DELETE acquérir des verrous.

Sans verrouillage optimisé, les prédicats de requête sont vérifiés ligne par ligne dans une analyse en prenant d'abord un verrou de ligne de mise à jour (U). Si le prédicat est satisfait, un verrou de ligne exclusif (X) est pris avant de mettre à jour la ligne et conservé jusqu'à la fin de la transaction.

Avec le verrouillage optimisé et lorsque le READ COMMITTED niveau d’isolation d’instantané (RCSI) est activé, les prédicats peuvent être vérifiés de manière optimiste sur la dernière version validée de la ligne sans prendre de verrous. Si le prédicat n’est pas satisfait, la requête passe à la ligne suivante de l’analyse. Si le prédicat est satisfait, un verrou de ligne X est pris pour mettre à jour la ligne.

En d’autres termes, le verrou est pris après la qualification de la ligne pour modification. Le verrou de ligne X est libéré dès que la mise à jour de ligne est terminée, avant la fin de la transaction.

Étant donné que l’évaluation des prédicats est effectuée sans acquisition de verrous, les requêtes concurrentes modifiant différentes lignes ne se bloquent pas les unes les autres.

Par exemple:

/* Confirm that optimized locking and read committed snapshot isolation (RCSI) are both enabled on this database. */
SELECT database_id,
       name,
       is_accelerated_database_recovery_on,
       is_optimized_locking_on,
       is_read_committed_snapshot_on
FROM sys.databases
WHERE name = DB_NAME();

CREATE TABLE t1
(
a int NOT NULL,
b int NULL
);

INSERT INTO t1
VALUES (1,10),(2,20),(3,30);
GO

Session 1	Session 2
`BEGIN TRANSACTION;` `UPDATE t1` `SET b = b + 10` `WHERE a = 1;`
	`BEGIN TRANSACTION;` `UPDATE t1` `SET b = b + 10` `WHERE a = 2;`
`COMMIT TRANSACTION;`
	`COMMIT TRANSACTION;`

Sans verrouillage optimisé, la session 2 est bloquée, car la session 1 contient un verrou U sur la ligne que la session 2 doit mettre à jour. Toutefois, avec le verrouillage optimisé, la session 2 n’est pas bloquée, car les verrous U ne sont pas pris. De plus, dans la dernière version validée de la ligne 1, la colonne a est égale à 1, ce qui ne répond pas au prédicat de la session 2.

Le LAQ est réalisé de manière optimiste en partant du principe qu'une ligne ne sera pas modifiée après la vérification du prédicat. Si le prédicat est satisfait et que la ligne n’a pas été modifiée après avoir vérifié le prédicat, elle est modifiée par la transaction actuelle.

Étant donné que les U verrous ne sont pas activés, une transaction simultanée peut modifier la ligne après que le prédicat a été évalué. S’il existe une transaction active contenant un X verrou TID sur la ligne, le moteur de base de données attend qu’elle se termine. Si la ligne a changé après l’évaluation du prédicat précédemment, le moteur de base de données réévalue (requalifie) le prédicat avant de modifier la ligne. Si le prédicat est toujours satisfait, la ligne est modifiée.

La requalification de prédicat est prise en charge par un sous-ensemble des opérateurs du moteur de requête. Si la réévaluation du prédicat est nécessaire, mais que le plan de requête utilise un opérateur qui ne prend pas en charge la requalification de prédicat, le moteur de base de données abandonne en interne le traitement des instructions et le redémarre sans LAQ. Lorsqu’un tel abandon se produit, l’événement étendu lock_after_qual_stmt_abort se déclenche.

Certaines instructions, par exemple UPDATE des instructions avec l’affectation de variable et des instructions avec la clause OUTPUT , ne peuvent pas être abandonnées et redémarrées sans modifier leur sémantique. Pour de telles déclarations, LAQ n'est pas utilisé.

Dans l’exemple suivant, le prédicat est réévalué, car une autre transaction a changé la ligne :

CREATE TABLE t3
(
a int NOT NULL,
b int NULL
);

INSERT INTO t3 VALUES (1,10),(2,20),(3,30);
GO

Session 1	Session 2
`BEGIN TRANSACTION;` `UPDATE t3` `SET b = b + 10` `WHERE a = 1;`
	`BEGIN TRANSACTION;` `UPDATE t3` `SET b = b + 10` `WHERE a = 1;`
`COMMIT TRANSACTION;`
	`COMMIT TRANSACTION;`

Ignorer les verrous d’index (SIL)

Avec le verrouillage TID, les verrous de ligne exclusifs à courte durée (X) et les verrous de page exclusifs à l’intention (IX) sont utilisés pour modifier les lignes. Lorsque RCSI et LAQ sont utilisés, ces verrous sont nécessaires uniquement s’il peut y avoir d’autres requêtes accédant à la ligne tout en attendant qu’elle soit stable. Parmi les exemples de telles requêtes, on trouve celles qui s'exécutent sous le niveau d'isolation REPEATABLE READ ou SERIALIZABLE et qui utilisent les indications de verrouillage correspondantes. Ces requêtes sont appelées requêtes de verrouillage de ligne (RLQ).

Lorsqu’aucune des requêtes RLQ n’accède à une ligne, le moteur de base de données peut ignorer la prise de verrous de ligne et de page lors de la modification d’une ligne et utiliser uniquement un latch de page exclusif. Cette optimisation réduit la surcharge de verrouillage tout en préservant la sémantique des transactions ACID. Ignorer les verrous de ligne et de page bénéficie particulièrement aux transactions qui modifient un grand nombre de lignes.

Actuellement, l’optimisation SIL est utilisée dans les cas suivants uniquement :

INSERT déclarations sur les tas.
- IX les verrous de page sont ignorés.
UPDATE instructions sur les indexes clusterisés, les indexes non clusterisés et les tas.
- IX les verrous de page et X les verrous de ligne sont ignorés.

L’optimisation SIL n’est actuellement pas utilisée dans les cas suivants :

InstructionsDELETE .
UPDATE instructions sur les tas si la ligne contient des pointeurs de renvoi existants ou si de nouveaux pointeurs de renvoi sont ajoutés lors de la mise à jour.
Si la ligne modifiée comporte des colonnes à l’aide des types de données LOB, tels que varchar(max), nvarchar(max), varbinary(max) et json.
Pour les lignes des pages qui ont été fractionnées dans la même transaction.

Heuristiques LAQ

Comme décrit dans Lock after qualification (LAQ), lorsque LAQ est utilisé, les instructions utilisant des opérateurs de requête qui ne prennent pas en charge la requalification de prédicat peuvent être redémarrées et traitées en interne sans LAQ. Si cela se produit fréquemment, la surcharge de retraitement peut devenir importante. Pour réduire la surcharge, le verrouillage optimisé utilise un mécanisme de rétroaction heuristique qui désactive LAQ si la surcharge dépasse les seuils.

Pour les besoins du mécanisme de commentaires, le travail effectué par une instruction est mesuré dans le nombre de lectures logiques. Si le moteur de base de données modifie une ligne modifiée par une autre transaction après le début du traitement des instructions, le travail effectué par l’instruction est traité comme potentiellement gaspillé, car l’instruction peut avoir besoin d’être reprocessée.

À mesure que les instructions s’exécutent, le moteur de base de données gère les données de commentaires LAQ qui suivent le travail potentiellement gaspillé, les occurrences du retraitement des instructions et le travail total effectué par les instructions susceptibles d’être rerétablies.

LaQ est désactivée si le ratio du travail potentiellement gaspillé au travail total, ou si le ratio du nombre d’instructions reprocessées au nombre total d’instructions dépassent leurs seuils respectifs. Si ces deux ratios tombent sous les seuils, LAQ est réactivé.

Les données de commentaires LAQ sont suivies à deux niveaux :

Pour un plan de requête.
- Le moteur de base de données commence à suivre les commentaires LAQ pour un plan sur la première occurrence du retraitement d’instruction.
- Si une requête est capturée dans le Magasin des requêtes, les commentaires LAQ sont également capturés dans le Magasin des requêtes. Le moteur de base de données utilise ces commentaires pour activer ou désactiver LAQ pour le plan si la base de données redémarre.
- Les plans de requête avec des commentaires LAQ capturés ont une ligne avec une valeur correspondante plan_id dans la vue de catalogue sys.query_store_plan_feedback. Les colonnes feature_id et feature_desc sont définies sur 4 et LAQ Feedback respectivement.
Pour une base de données.
- Les commentaires sont agrégés pour toutes les instructions qui n’ont pas de commentaires au niveau du plan de requête, par exemple si une requête n’est pas capturée dans le Store des requêtes.
- Les commentaires sont suivis depuis le démarrage de la base de données et recréés après chaque démarrage.

Lorsque vous décidez s’il faut utiliser LAQ pour une instruction, le système utilise les commentaires du plan de requête s’il est disponible. Sinon, il utilise les commentaires au niveau de la base de données. Cela signifie que certaines instructions peuvent s’exécuter avec LAQ, et certaines peuvent s’exécuter sans LAQ. Par exemple, LAQ peut être désactivé pour un plan de requête, mais activé pour la base de données, et inversement.

Limitations de LAQ

Le verrouillage après qualification n’est pas utilisé dans les scénarios suivants :

Lorsqu’il est désactivé par l’heuristique LAQ.
Lorsque des indicateurs de verrouillage en conflit, tels que UPDLOCK, READCOMMITTEDLOCK, XLOCKou HOLDLOCK sont utilisés.
Lorsque le niveau d’isolation des transactions est autre que READ COMMITTED, ou lorsque l’option READ_COMMITTED_SNAPSHOT de base de données est désactivée.
Lorsque la table modifiée a un index columnstore.
Lorsque l’instruction DML inclut une attribution de variable.
Lorsque l’instruction DML a une OUTPUT clause.
Lorsque l’instruction DML utilise plusieurs opérateurs de recherche ou d’analyse d’index pour lire les lignes en cours de modification.
Dans des instructions MERGE.

Changements de comportement des requêtes avec verrouillage optimisé et RCSI

Les charges de travail simultanées sous RCSI (isolement de capture instantanée de lecture validée) qui s'appuient sur un ordre d'exécution strict des transactions peuvent présenter des différences de comportement des requêtes lorsque le verrouillage optimisé est activé.

Prenons l’exemple suivant où la transaction T2 met à jour la table t4 en fonction de la colonne b qui a été mise à jour lors de la transaction T1.

CREATE TABLE t4
(
a int NOT NULL,
b int NULL
);

INSERT INTO t4
VALUES (1,1);
GO

Session 1	Session 2
`BEGIN TRANSACTION T1;` `UPDATE t4` `SET b = 2` `WHERE a = 1;`
	`BEGIN TRANSACTION T2;` `UPDATE t4` `SET b = 3` `WHERE b = 2;`
`COMMIT TRANSACTION;`
	`COMMIT TRANSACTION;`

Analysons le résultat du scénario précédent avec et sans verrou après qualification (LAQ).

Sans LAQ

Sans LAQ, l'instruction UPDATE de la transaction T2 est bloquée, en attendant la fin de la transaction T1. Une fois la T1 terminée, la T2 met à jour la ligne définissant la colonne b en 3, car son prédicat est satisfait.

Une fois les deux transactions validées, la table t4 contient les lignes suivantes :

 a | b
 1 | 3

Avec LAQ

Avec LAQ, la transaction T2 utilise la dernière version validée de la ligne où la colonne b est égale à 1 pour évaluer son prédicat (b = 2). La ligne ne remplit pas les conditions requises ; par conséquent, elle est ignorée et l'instruction se termine sans blocage par la transaction T1. Dans cet exemple, le LAQ supprime le blocage, mais entraîne des résultats différents.

Une fois les deux transactions validées, la table t4 contient les lignes suivantes :

 a | b
 1 | 2

Important

Même sans LAQ, les applications ne doivent pas supposer que le moteur de base de données garantit un ordre strict sans utiliser d’indicateurs de verrouillage lorsque les niveaux d’isolation basés sur le contrôle de version de ligne sont utilisés. Nous recommandons généralement aux clients qui exécutent des charges de travail simultanées sous RCSI et qui s'appuient sur un ordre d'exécution strict des transactions (comme dans l'exemple précédent) d'utiliser des niveaux d'isolement plus stricts, tels que REPEATABLE READ et SERIALIZABLE.

Ajouts de diagnostic pour le verrouillage optimisé

Les améliorations suivantes vous aident à surveiller et à résoudre les blocages lorsque le verrouillage optimisé est activé :

Types d’attente pour le verrouillage optimisé
- XACT types d'attente pour le verrou TID S et les descriptions des ressources dans sys.dm_os_wait_stats :
  - LCK_M_S_XACT_READ : se produit lorsqu’une tâche attend un verrou partagé sur un type XACTwait_resource, avec l’intention de lire.
  - LCK_M_S_XACT_MODIFY : se produit lorsqu’une tâche attend un verrou partagé sur un type XACTwait_resource, avec l’intention de modifier.
  - LCK_M_S_XACT : se produit lorsqu’une tâche attend un verrou partagé sur un type XACTwait_resource et dont l’intention ne peut pas être déduite. Ce scénario n’est pas courant.
Visibilité des ressources de verrouillage
- Ressources de verrouillage XACT. Pour plus d'informations, voir resource_description dans sys.dm_tran_locks.
Visibilité des ressources d’attente
- Ressources d’attente XACT. Pour plus d’informations, consultez wait_resourcesys.dm_exec_requests.
Graphique d’interblocage
- Sous chaque ressource du rapport d’interblocage <resource-list>, chaque élément <xactlock> signale les ressources sous-jacentes et des informations spécifiques pour les verrous de chaque membre d’un interblocage. Pour plus d'informations et pour obtenir un exemple, consultez Verrouillage optimisé et interblocages.
Événements étendus
- L'événement lock_after_qual_stmt_abort se déclenche lorsqu'une instruction est traitée à nouveau dans le système à cause d'un conflit avec une autre transaction. Pour plus d’informations, consultez verrou après qualification (LAQ).
- L’événement locking_stats se déclenche pour chaque base de données toutes les minutes et fournit des statistiques de verrouillage agrégées pour l’intervalle de temps, telles que le nombre d’escalades de verrous, si le verrouillage TID et les composants LAQ de verrouillage optimisé sont activés et le nombre de requêtes où LAQ n’a pas été utilisé pour différentes raisons. Cet événement se déclenche même si le verrouillage optimisé est désactivé.
- Dans SQL Server et Azure SQL Managed Instance, l’événement locking_stats2 se déclenche toutes les quelques minutes et fournit les statistiques sur les verrous d’index skip et les heuristiques LAQ pour l’intervalle de temps.

Meilleures pratiques relatives au verrouillage optimisé

Activer l’isolement de capture instantanée à lecture validée (RCSI)

Pour optimiser les avantages du verrouillage optimisé, il est recommandé d’activer l’isolation de capture instantanée validée en lecture (RCSI) sur la base de données et d’utiliser READ COMMITTED l’isolation comme niveau d’isolation par défaut.

Dans Azure SQL Database et sql Database dans Microsoft Fabric, RCSI est activé par défaut et READ COMMITTED est le niveau d’isolation par défaut. Lorsque RCSI est activé et que vous utilisez le niveau d’isolement READ COMMITTED, les lecteurs lisent une version de la ligne à partir de l’instantané pris au début de l’instruction. Avec LAQ, les enregistreurs qualifient les lignes par prédicat en fonction de la dernière version validée de la ligne sans acquérir de verrous U. Avec LAQ, une requête attend uniquement si la ligne est éligible et qu'il y a une transaction d'écriture active sur cette ligne. La qualification basée sur la dernière version validée et le verrouillage des seules lignes qualifiées réduisent le blocage et augmentent la concurrence.

Éviter les indicateurs de verrouillage

Bien que les indicateurs de table et de requête tels que UPDLOCK, READCOMMITTEDLOCK, XLOCK, HOLDLOCK, etc. soient respectés lorsque le verrouillage optimisé est activé, ils réduisent l’avantage du verrouillage optimisé. Les hints de verrouillage forcent le moteur de base de données à prendre des verrous de ligne ou de page et à les conserver jusqu’à la fin de la transaction, afin de respecter l'objectif des hints de verrouillage. Certaines applications ont une logique dans laquelle les indicateurs de verrou sont nécessaires, par exemple, pour lire une ligne avec l’indicateur UPDLOCK, puis la mettre à jour ultérieurement. Nous vous recommandons d’utiliser des indicateurs de verrou uniquement si nécessaire.

Avec le verrouillage optimisé, il n’existe aucune restriction sur les requêtes existantes et les requêtes n’ont pas besoin d’être réécrites. Les requêtes qui n’utilisent pas d’indicateurs sont celles qui bénéficient le plus d’un verrouillage optimisé.

Un indicateur de table sur une table d’une requête ne désactive pas le verrouillage optimisé pour les autres tables de la même requête. En outre, le verrouillage optimisé n'affecte que le comportement de verrouillage des tables mises à jour par une instruction DML telle que INSERT, UPDATE, DELETE ou MERGE. Par exemple:

CREATE TABLE t5
(
a int NOT NULL,
b int NOT NULL
);

CREATE TABLE t6
(
a int NOT NULL,
b int NOT NULL
);
GO

INSERT INTO t5 VALUES (1,10),(2,20),(3,30);
INSERT INTO t6 VALUES (1,10),(2,20),(3,30);
GO

UPDATE t5 SET t5.b = t6.b
FROM t5
INNER JOIN t6 WITH (UPDLOCK)
ON t5.a = t6.a;

Dans l’exemple de requête précédent, seule la table t6 est affectée par l’indicateur de verrouillage, tandis que t5 peut toujours bénéficier d’un verrouillage optimisé.

UPDATE t5
    SET t5.b = t6.b
FROM t5 WITH (REPEATABLEREAD)
     INNER JOIN t6
         ON t5.a = t6.a;

Dans l’exemple de requête précédent, seule la table t5 utilise le niveau d’isolement REPEATABLE READ et conserve les verrous jusqu’à la fin de la transaction. D’autres mises à jour de t5 peuvent toujours bénéficier d’un verrouillage optimisé. Il en va de même pour l’indicateur HOLDLOCK.

Forum aux questions (FAQ)

Le verrouillage optimisé est-il activé par défaut dans les bases de données nouvelles et existantes ?

Dans Azure SQL Database, Azure SQL Managed Instance^AUTD, et SQL Database dans Microsoft Fabric, oui. Dans SQL Server 2025 (17.x) le verrouillage optimisé est désactivé par défaut, mais peut être activé sur n’importe quelle base de données utilisateur qui a accéléré la récupération de base de données activée.

Comment détecter si le verrouillage optimisé est activé ?

Voir Le verrouillage optimisé est-il activé ?

Puis-je forcer les requêtes à créer des blocages malgré le verrouillage optimisé ?

Si RCSI est activé, utilisez l’indice de table READCOMMITTEDLOCK pour forcer le blocage entre deux requêtes lorsque le verrouillage optimisé est activé.

Le verrouillage optimisé est-il utilisé sur les réplicas secondaires en lecture seule ?

Non, car les instructions DML ne peuvent pas s’exécuter sur des réplicas en lecture seule, et les verrous de ligne et de page correspondants ne sont pas pris.

Le verrouillage optimisé est-il utilisé lors de la modification des données dans tempdb et dans des tables temporaires ?

Pas pour l'instant.

Rétroaction

Cette page vous a-t-elle été utile ?

Last updated on 2025-11-24