La directive SELECT ... FOR UPDATE, classée comme opération de lecture actuelle (current read) sous InnoDB, ne génère pas automatiquement un verrou de ligne pur. La précision du cadenas (enregistrement, intermédiaire ou tableau entier) varie strictement selon l'exploitation des indexes lors du filtrage et le paramètre d'isolement de la session. Un verrou restrictif au seul niveau de l'enregistrement n'est octroyé qu'en cas de concordance absolue sur une clé primaire ou un index unique.

1. Mécanisme sous-jacent du verrou exclusif

L'activation du curseur FOR UPDATE force immédiatement InnoDB à poser un verrou exclusif (X) sur les ressources identifiées. Cet état suspend toute tentative concurrente de lecture protégée, de mise à jour ou de suppression jusqu'à validation ou rollback. La portée dynamique de ce cadastre dépend de deux leviers :

• La structure indexée sollicitée par les prédicats WHERE.
• La grille d'isolement transactionnel (la valeur REPEATABLE READ restant dominante).

2. Grille de verrouillage par profil de requête

A. Concordance exacte via Clé Primaire ou Index Unique

Cette configuration offre la meilleure capacité de parallélisme. Le Moteur repère l'occurrence cible en temps constant et installe un Record Lock. Aucun voisin ni aucun espace mémoire adjacent n'est contaminé.

-- Identification directe par clé structurée
SELECT product_qty FROM catalog_stock 
WHERE prod_ref = 'REF-A8821' FOR UPDATE;

B. Usage d'Index Standard (Contrainte non unique)

Face à un index classique, même si le résultat final pointe une seule entrée, le système assemble un Next-Key Lock (combinaison verrou de ligne + verrou d'espace). Ce mécanisme garantit l'intégrité face aux anomalies de répétition propres au mode RR.

• Verrou exclusif statique sur la ligne correspondante.
• Verrou d'espace (Gap) sur les intervalles adjacents de la structure B+.

-- Filtrage sur index classique
SELECT warehouse_zone FROM catalog_stock 
WHERE district_tag = 'FR-SUD' FOR UPDATE;

C. Défaillance Index ou Parcourt Séquentiel

Lorsque l'optimiseur est contraint à un balayage complet (conversion de type silencieuse, fonctions enveloppantes sur les colonnes scrutées, ou nullité index), le verrou s'étend à l'échelle de l'objet table. Cette fermeture radicale gèle systématiquement toute interaction transactionnelle parallèle.

SELECT warehouse_zone FROM catalog_stock 
WHERE batch_nbr = '99421' FOR UPDATE; -- Scanne global → Verrou universel

-- Absence totale de restriction
SELECT warehouse_zone FROM catalog_stock 
FOR UPDATE;

3. Spécificité des opérateurs ranges sur indexes uniques

Une interrogation range sur une clé principale (BETWEEN, >, <) active également un Next-Key Lock. L'arbre parcourt chaque feuille concernée et fige les intervalles supérieurs. Seul un croisement strictement monotonique (prod_ref BETWEEN 'REF-A8821' AND 'REF-A8821') autorise un retour au verrou de ligne élémentaire.

4. Validation expérimentale comparative

Schéma de test catalog_stock(prod_ref CHAR PRIMARY KEY, district_tag VARCHAR(15)).

5. Bonnes pratiques de modélisation

1. Ajustement de l'isolement : Passer à READ COMMITTED supprime les Gap Locks, rendant les index standards compatibles avec des Record Locks. Attention : cette flexibilité anesthésie la barrière contre les lectures fantômes.
2. Optimisation des filtres : Canaliser prioritairement les conditions vers des identifiants uniques primaires pour saturer au minimum les queues de contention.
3. Stérilisation des fuites : Interdire formellement les transformations implicitement applicatives sur les clés, ainsi que les patterns préfixés (LIKE '%...'}), qui provoquent automatiquement des montées en puissance tabulaires.
4. Restriction dynamique : Dimensionner étroitement les intervalles BETWEEN afin de circonscrire l'emprise des verrous Next-Key et minimiser les délais de blocage.
5. Supervision continue : Audit régulier des plans d'exécution (EXPLAIN) pour anticiper les rétrogradations index vers parcours séquentiles.