Comprendre les problèmes de Database Row Locking et de concurrency dans MySQL

Ligne de base de données Dans MySQL, le verrouillage contrôle précisément quelle transaction est autorisée à lire ou à écrire quelles lignes et à quel moment, ce qui permet d'éviter les mises à jour perdues et les lectures non validées. Je vais vous montrer étape par étape comment les verrous, MVCC et comment les niveaux d'isolation interagissent, où surviennent les problèmes de concurrence et comment concevoir les requêtes, les index et les transactions de manière à éviter les blocages.

Points centraux

Pour que tu puisses rapidement cerner les points sur lesquels je me concentre dans cet article, je vais résumer les principes directeurs les plus importants et les mettre brièvement en parallèle. Tu disposeras ainsi d'une structure concise pour les analyses plus approfondies qui suivent Explications.

• Verrous de rangée limiter les conflits à des lignes individuelles plutôt qu'à des tableaux entiers.
• MVCC permet une lecture rapide sans verrous partagés permanents.
• Isolation détermine quelles anomalies sont autorisées.
• Touche Gap/Next Bloquer les lacunes de l'index contre les fantômes.
• Meilleures pratiques réduisent sensiblement les blocages et les interblocages.

Je vais ensuite traduire ces points en mesures concrètes qui me permettront de garantir la sécurité et la rapidité des instances MySQL en production. Chaque recommandation vise à réduire Blocage, des données cohérentes et des parcours diagnostiques clairs.

Pourquoi le contrôle de la concurrence est-il nécessaire ?

Les accès simultanés entrent en conflit dès que plusieurs sessions tentent de lire ou d'écrire les mêmes lignes, c'est pourquoi j'ai opté pour une Limites des transactions Huitièmement. Sans règles, on risque des mises à jour perdues, des lectures sales, des lectures non reproductibles et des objets fantômes, qui finissent par entraîner des décisions erronées dans le code de l'application. J'empêche cela en garantissant la cohérence des lectures et en rendant les conflits d'écriture visibles dès le début, au lieu de les écraser silencieusement. Plus il y a d'utilisateurs actifs en parallèle, plus les petits objets de verrouillage et les courtes temps d'arrêt. Ceux qui ignorent cela s'exposent à des erreurs de données, à de longues files d'attente et à des délais d'expiration.

Principes de base du verrouillage de lignes dans MySQL

Le verrouillage par ligne applique des verrous à des lignes individuelles, ce qui permet aux autres lignes de rester libres et d'offrir davantage de Parallélisme est créé. Un verrou exclusif protège les opérations d'écriture jusqu'à la validation, tandis que les accès en lecture utilisent, selon le niveau d'isolation, des verrous partagés ou des instantanés MVCC. Les verrous d'intention servent de signaux de haut niveau afin que le moteur puisse vérifier plus rapidement la compatibilité des verrous. Je note toujours que même de petites mises à jour peuvent affecter de nombreuses lignes si les conditions WHERE sont imprécises et qu'il n'y a pas de Index conduit à. La précision du filtre évite les larges plages d'exclusion et préserve la concurrence.

L'interaction avec les index est également importante, car InnoDB verrouille via les chemins d'index ; des clés manquantes ou inadaptées augmentent considérablement le nombre de lignes concernées. Si une instruction effectue un balayage complet, le champ de verrouillage s'agrandit, ce qui allonge les temps d'attente et favorise les interblocages. Je prévois donc dès le départ les clés adaptées aux chemins fréquents et je formule les clauses WHERE de manière aussi spécifique que possible. Ainsi, mes verrous restent restreints et les autres transactions aboutissent plus rapidement à Accès. C'est le réglage le plus simple pour obtenir un verrouillage en douceur.

Verrouillage pessimiste vs verrouillage optimiste

Le verrouillage pessimiste part du principe qu'il y aura des conflits et procède à un verrouillage précoce, ce qui renforce l'intégrité mais prend du temps, tandis que optimiste Les systèmes en production ne vérifient qu'à la fin si les données ont changé. Dans les configurations MySQL concrètes, je combine les deux approches : pour les comptes critiques, j'utilise FOR UPDATE ; pour les entités qui entrent rarement en conflit, j'utilise les versions. Une colonne de version ou un horodatage me permet, lors de la mise à jour, de déterminer si quelqu'un a été plus rapide, sans bloquer la ligne de manière permanente. En cas de conflit, je répète la transaction de manière ciblée ou j'exécute une logique métier adaptée. Je répartis ainsi la charge de manière plus efficace, je réduis les temps d'attente et je maintiens la Correction haut.

Je choisis la stratégie au cas par cas : les nombreuses opérations de lecture simultanées tirent profit d'approches optimistes, tandis que les écritures comptables ou de stock hautement critiques nécessitent des verrous exclusifs courts mais clairs. L'objectif reste toujours de ne bloquer que le strict nécessaire et de détecter les conflits à un stade précoce. Grâce à cette approche, j'évite les longues chaînes de sessions en attente. Cela permet d'augmenter le débit et Fiabilité dans la vie quotidienne.

Comprendre les niveaux d'isolation et le MVCC

Le niveau d'isolation détermine le nombre d'anomalies que j'autorise et l'intensité des verrous appliqués par MySQL ; c'est pourquoi je choisis ce niveau en fonction du cas d'utilisation. READ COMMITTED empêche les lectures non validées, REPEATABLE READ garantit la cohérence des valeurs d'une transaction, et SERIALIZABLE impose l'ordre le plus strict. InnoDB utilise MVCC, afin que les lecteurs puissent presque toujours se passer de verrous partagés tout en obtenant des instantanés cohérents. Ceux qui utilisent cette technique doivent comprendre quand les verrous « gap » et « next-key » s'appliquent en plus pour éviter les « phantoms ». Pour en savoir plus, il est utile de consulter Détails sur les niveaux d'isolation, afin que tu puisses évaluer correctement les effets à chaque niveau.

Le tableau suivant répertorie les niveaux courants de protection contre les anomalies courantes et leur incidence sur les blocages, afin que je puisse faire le bon choix et éviter tout Blocage évite.

Niveau d'isolation	Anomalies autorisées	Comportement de verrouillage (en simplifié)	Utilisation typique
LIRE NON-COMMUNIQUÉ	Lectures erronées, données non réutilisables, fantômes	Peu de blocages, haut Risques	Rarement utile
READ COMMITTED	Non répétables, fantômes	Les lecteurs utilisent le MVCC, les rédacteurs X-Locks	Rapports, API avec un nombre élevé de lectures
LECTURE RÉPÉTABLE	Réduction des phantoms grâce à Next-Key	Grande cohérence de lecture, ciblée Gap-Verrouillage	Par défaut dans InnoDB
SERIALIZABLE	Aucune anomalie	Des barrières plus larges, moins Parallélisme	Processus hautement critiques

Je commence généralement par REPEATABLE READ et j'apporte des corrections ciblées lorsque les requêtes sont trop bloquées à cause des verrous Next-Key. À l'inverse, je n'utilise SERIALIZABLE que lorsque cela est absolument indispensable d'un point de vue technique, car sinon les temps d'attente s'accumulent. En faisant un choix clair pour chaque charge de travail, je garantis la cohérence des données tout en protégeant la Performance. Cette approche permet de gagner du temps en matière d'assistance, car les pics de verrouillage inattendus sont moins fréquents. Le système reste ainsi prévisible, même lorsque le nombre d'utilisateurs augmente.

La concurrence MySQL en pratique

Une bonne gestion de la concurrence commence par des requêtes bien formulées, qui ne sélectionnent que les lignes réellement nécessaires, afin qu'InnoDB puisse Ligne-peut entraîner des blocages. Je veille à ce que les conditions de filtrage soient « sargables », c'est-à-dire qu'elles s'appuient sur des index et n'imposent pas d'appels de fonctions sur les colonnes. Je veille à ce que les mises à jour soient ciblées : clause WHERE claire, index adapté, pas de jointures inutiles dans la même instruction. Pour les cas de réservation, j'utilise FOR UPDATE avec parcimonie et uniquement pour les enregistrements réellement concernés. De plus, j'évite les longues interactions utilisateur entre BEGIN et COMMIT, car chaque seconde augmente le temps d'attente d'autres sessions.

Lors d'insertions dans des espaces d'index denses, je tiens compte du fait que des verrous Next-Key peuvent s'appliquer, ce qui entraîne une augmentation du nombre de transactions en attente. Je répartis les points chauds en dispersant les espaces de clés ou en déchargeant le chemin d'écriture vers une petite file d'attente indépendante. Cela me permet de réduire les collisions sur la table la plus sollicitée. Ce réglage fin est plus efficace que l'augmentation des délais d'expiration, car moins Conflits apparaissent. C'est précisément pour cette raison qu'il est utile de mesurer les accès aux données avant la mise en service.

Problèmes typiques liés à la concurrence : blocage, interblocage, portée des verrous

Un blocage se produit lorsqu'une transaction attend une ligne déjà verrouillée ; c'est pourquoi je veille à ce que les transactions soient courtes et que la Quantité limiter. Des blocages surviennent lorsque deux transactions se bloquent mutuellement ; MySQL détecte ce phénomène et en interrompt une. Je réagis à cela par des tentatives de reprise ciblées et un ordre d'accès cohérent sur tous les chemins de code. L'escalade des verrous est plus rare dans InnoDB, mais des limites internes restreignent la charge administrative ; les scans volumineux rapprochent le moteur de ces limites. Si vous constatez des blocages récurrents, vous devriez Détection et gestion des blocages examiner systématiquement la situation et éliminer les sources de conflit, plutôt que de se contenter d'augmenter les délais d'attente.

D'après mon expérience, trois cas de figure sont particulièrement à l'origine de longs délais d'attente : les filtres non indexés sur des tables très sollicitées, l'utilisation de FOR UPDATE sans clause WHERE précise et une logique métier trop longue entre les étapes de lecture et d'écriture. Je les élimine en mesurant chaque chemin individuellement, en réduisant la durée de verrouillage et en optimisant les instructions SQL pour qu'elles utilisent les chemins d'index. De petites modifications apportées au filtre ou à l'ordre des mises à jour permettent souvent de débloquer des nœuds entiers. De telles corrections sont moins coûteuses que davantage Matériel informatique, car elles ont un effet durable. Ce n'est qu'ensuite qu'il vaut la peine d'envisager une expansion verticale ou horizontale.

Bonnes pratiques pour éviter les blocages et les interblocages

Je finalise rapidement les transactions et ne laisse aucun formulaire de saisie ouvert pendant que des verrous sont maintenus, car chaque seconde est une perte de temps inutile Files d'attente provoqué. Je traite toujours les tables et les lignes dans le même ordre afin d'éviter les dépendances cycliques. Pour les opérations de lecture pure, READ COMMITTED suffit souvent, tandis que pour les mises à jour critiques, j'utilise REPEATABLE READ ou, à court terme, FOR UPDATE. La conception d'index reste obligatoire : sans clé appropriée, une instruction verrouille rapidement beaucoup trop de lignes. La gestion des erreurs en fait également partie : j'intercepte les erreurs de blocage, j'enregistre tous les détails et j'essaie de trouver une solution courte et propre Retry.

La surveillance vient compléter le tout : je surveille les temps d'attente, le nombre de blocages et les plans de requêtes, et j'optimise en priorité les pics qui me semblent suspects. Les petites améliorations apportées aux chemins d'accès fréquents ont un impact considérable, car elles s'appliquent à chaque requête. J'obtiens ainsi moins de blocages, un débit plus élevé et des temps de réponse fiables. Cette approche s'avère bien plus efficace dans le quotidien que des refontes à grande échelle. Des routines bien conçues valent mieux que des solutions globales Actions presque toujours.

Conseils spécifiques à MySQL pour améliorer la concurrence

J'utilise délibérément l'autocommit : certaines instructions en tirent profit, tandis que les modifications liées entre elles sont regroupées dans une instruction courte et claire Transaction atterrissent. J'utilise SELECT … FOR UPDATE avec parcimonie et uniquement pour les enregistrements que je dois vraiment réserver. Je transfère les rapports volumineux vers des répliques ou des systèmes analytiques afin que les charges de travail OLTP n'aient pas à attendre. De plus, je vérifie régulièrement quelles instructions maintiennent un nombre inhabituellement élevé de verrous et pourquoi. Si vous souhaitez approfondir le sujet, je vous recommande de consulter la Moteur de stockage InnoDB et d'évaluer de manière réfléchie les structures d'index dans le contexte de son propre schéma avant la mise en production de la prochaine version.

Je minimise les points chauds en choisissant les clés primaires de manière à ce que la charge d'écriture ne se concentre pas en permanence à la fin d'un index croissant de façon monotone. Je divise également les opérations par lots en petits morceaux afin de ne pas générer de longs verrous exclusifs. Grâce à ces techniques, les verrous durent moins longtemps et les conflits diminuent de manière mesurable. Cela réduit le taux d'erreurs et l'application répond plus rapidement. Je libère ainsi des ressources sans avoir à créer immédiatement de nouvelles Serveur de construire.

Suivi et analyse : ce que je mesure

Je commence par analyser les indicateurs relatifs aux temps d'attente de verrouillage, au nombre de blocages, aux transactions longues et aux requêtes les plus longues en termes de durée d'exécution, afin d'identifier les principaux Levier Je repère les problèmes. Le schéma de performances, la commande SHOW ENGINE INNODB STATUS et les journaux des requêtes lentes me fournissent des indications concrètes. Ensuite, j'examine les plans des requêtes les plus problématiques et je vérifie s'il manque des index ou si les filtres ne sont pas optimisables. Dès que j'élimine les goulots d'étranglement, j'observe l'effet sur plusieurs phases de charge. Ce cycle de mesure, de modification et de vérification permet de Qualité la concurrence augmente sensiblement.

Pour obtenir des résultats fiables, j'ai besoin de données de test réalistes et de véritables modèles d'accès, et pas seulement de tests synthétiques ponctuels. Les profils de charge avec des sessions simultanées montrent comment les verrous fonctionnent réellement. De tels tests révèlent des points de congestion cachés qui, dans la pratique quotidienne, ne sont généralement détectés que tardivement. Tester les versions de cette manière permet d’éviter les surprises en production. Cela permet d’économiser de l’argent, du temps et des tracas à long terme. Vue.

Environnement d'hébergement et performances de la base de données

Une bonne concurrence repose sur un matériel performant, car tout retard d'E/S allonge le durée de la capture. Je veille à disposer de SSD rapides, d'une mémoire vive suffisante pour les pools de tampons et de chemins d'accès courts entre l'application et la base de données. Les réserves de CPU permettent d'exécuter des requêtes parallèles sans engorgement. Je réduis systématiquement les latences réseau afin que les allers-retours n'augmentent pas le temps de blocage effectif. En gardant ces conditions générales à l'esprit, on obtient des Services et moins d'avortements.

Les stratégies de mise à l'échelle judicieuses comptent également : répliques de lecture pour les rapports, partitionnement pour les très grands ensembles de données et systèmes distincts pour les charges de travail d'analyse. Je ne choisis l'option la plus judicieuse qu'après avoir effectué des mesures, et j'évite les décisions hâtives. L'architecture et la discipline SQL se complètent ; sans requêtes cohérentes, le matériel ne compense que temporairement. Avec un mélange cohérent, je réduis considérablement les conflits de verrouillage. Il en résulte une expérience utilisateur fiable, sans Temps d'attente.

Les types de verrous dans InnoDB en détail

Pour prendre des décisions éclairées concernant les chemins de requête, je connais parfaitement les principaux types de verrous : les verrous d'enregistrement bloquent des entrées d'index individuelles, les verrous de gap bloquent l'espace entre deux entrées d'index, et les verrous Next-Key combinent les deux. Ces derniers empêchent l'apparition de fantômes lors des balayages de plage. Les verrous d'intention d'insertion signalent l'intention d'effectuer des insertions et permettent des insertions parallèles dans différents espaces vides sans se gêner inutilement. Lors de recherches univoques via un index unique, InnoDB réduit le verrou à un Record-Lock, ce qui minimise les blocages. Dès qu’un prédicat de plage entre en jeu (BETWEEN, >, LIKE avec préfixe), un Next-Key-Lock s’applique souvent, entraînant ainsi une zone de verrouillage plus large.

C'est pourquoi je conçois les requêtes de manière à ce qu'elles s'appuient autant que possible sur des index uniques ou hautement sélectifs. Le WHERE n'est pas le seul facteur déterminant : l'ORDER BY, le LIMIT et l'ordre des JOIN influencent également le chemin d'index choisi – et donc l'étendue des verrous. Une reformulation ciblée, qui utilise un ORDER BY avec un index adapté, peut éviter les verrous Next-Key et réduire considérablement les temps d'attente.

Utiliser les lectures verrouillées de manière ciblée

Les lectures verrouillées sont utiles lorsque je dois réserver des lignes ou coordonner des mises à jour concurrentes. Dans MySQL, j'utilise :

• SELECT … FOR UPDATE : verrou exclusif sur les lignes lues, adapté aux réservations avant une mise à jour.
• SELECT … FOR SHARE (ou LOCK IN SHARE MODE dans les versions antérieures) : verrouillage partagé permettant d'obtenir des lectures cohérentes en lecture seule.
• NOWAIT et SKIP LOCKED : pour éviter les longs délais d'attente – NOWAIT interrompt immédiatement l'opération, tandis que SKIP LOCKED ignore les lignes verrouillées.

Un modèle courant pour les files d'attente de tâches :

START TRANSACTION;
SELECT id, payload
FROM jobs
WHERE status = 'ready'
ORDER BY priority, id
LIMIT 50
FOR UPDATE SKIP LOCKED;
-- marquer comme ' processing ' et valider
UPDATE jobs SET status = 'processing' WHERE id IN (...);
COMMIT;

Voici comment je traite les tâches en parallèle sans qu'elles ne se bloquent mutuellement. Il est important de veiller à utiliser des clauses WHERE précises, un index adapté sur (status, priority, id) et des transactions courtes.

Comprendre les verrous de métadonnées (MDL)

Outre les verrous de ligne, il existe des verrous de métadonnées qui coordonnent les opérations DDL et DML. Chaque requête en cours maintient un verrou de lecture MDL sur les tables concernées ; les opérations DDL nécessitent des verrous MDL exclusifs. Une commande ALTER TABLE lancée sans précaution peut donc être mise en attente jusqu’à ce que des transactions ou des rapports de longue durée se terminent ; à l’inverse, un DDL bloque à son tour les nouveaux accès DML. Je planifie donc les modifications de schéma en dehors des heures de pointe, je réduis la durée des transactions et je vérifie avant les déploiements si des sessions maintiennent des tables ouvertes pendant plusieurs minutes. Les variantes DDL en ligne atténuent considérablement ces problèmes, mais ne remplacent pas la rigueur en matière de durées de transaction. Dans le cadre de la surveillance, je surveille spécifiquement les temps d'attente MDL, car ils signalent des goulots d'étranglement évitables.

Clés étrangères, chaînes de contraintes et indexation obligatoire

Les clés étrangères améliorent la qualité des données, mais augmentent l'empreinte des verrous. InnoDB vérifie la cohérence à l'aide d'index : s'il n'y en a pas sur les colonnes de clés étrangères, cela risque d'entraîner des balayages étendus et des verrous prolongés. Je veille donc à ce que chaque colonne de référence dispose d'un index. Les mises à jour/suppressions en cascade peuvent verrouiller plusieurs tables au cours d'une transaction et favoriser ainsi les interblocages. Je définis un ordre d'accès fixe pour toutes les tables concernées et je limite la taille des modifications. Lorsque les cascades sont rarement nécessaires d'un point de vue fonctionnel, j'étudie des alternatives : des étapes explicites et courtes avec des conditions WHERE claires, afin de maintenir la durée du verrouillage prévisible.

Auto-incrémentation, zones réactives et insertions en masse

Les clés primaires à croissance monotone créent un point chaud à la fin de l'index clusterisé. De nombreuses insertions parallèles s’y croisent, ce qui augmente les temps d’attente. Je répartis les clés (par exemple à l’aide de clés de partition ou d’un ID d’entité préfixé) ou j’utilise des tailles de lots courtes qui se valident proprement. Je contrôle le comportement d'auto-incrémentation via le mode de verrouillage : pour l'OLTP, je privilégie les paramètres qui autorisent les insertions parallèles et ne verrouillent que brièvement. Pour les lots volumineux, je vérifie si un chemin de type COPY ou de petits sous-ensembles reproductibles sont plus rapides. Il reste important de ne créer des index qu'après des chargements volumineux ou de décharger les index secondaires pendant ceux-ci afin de réduire les points chauds d'insertion.

Réplication et lectures cohérentes

Lors de la lecture de répliques, je tiens compte des décalages : sinon, un rapport pourrait afficher des données obsolètes. Pour obtenir des instantanés cohérents, je lance délibérément les transactions avec WITH CONSISTENT SNAPSHOT et je définis READ ONLY lorsqu'il s'agit uniquement d'une lecture. Je conserve ainsi une vue stable sur plusieurs instructions, sans verrouillages inutiles. Parallèlement, je veille à ce que l'application dispose de chemins tolérants en cas de retards de réplication ou, si nécessaire, bascule vers le serveur principal lorsque l'actualité absolue est cruciale. Cela réduit les surprises et explique les „ anomalies “ apparentes qui ne sont en réalité que des latences de réplication.

Configuration et stratégies de nouvelle tentative

J'ajuste judicieusement les délais d'attente des verrous et la détection : un paramètre innodb_lock_wait_timeout modéré empêche les sessions de rester bloquées pendant plusieurs minutes. Je détecte les interblocages de manière proactive et je les distingue clairement : je récupère brièvement l'erreur 1213 (interblocage) avec un backoff et un jitter ; j'interprète l'erreur 1205 (délai d'attente de verrou) comme un signal pour optimiser le chemin de requête. innodb_deadlock_detect est utile pour de nombreuses transactions courtes ; en cas de parallélisme extrêmement élevé, son rapport coût-bénéfice peut basculer – dans ce cas, l'équilibrage des points chauds est presque toujours la meilleure solution plutôt que de se contenter de modifier les paramètres.

Les tentatives de reprise ne sont fiables que si les opérations sont idempotentes. Je conçois les chemins de mise à jour de manière à ce qu'une nouvelle tentative aboutisse au même état final (par exemple, en utilisant des colonnes de version, des ensembles déterministes plutôt que des incréments, ou des événements métier clairs). Cela me permet d'éviter les doublons et de garantir la robustesse du code face aux conflits inévitables.

Exemples : lots sans blocages étendus

Je divise les modifications importantes en petits blocs indexés, en fonction de la clé primaire :

-- Exemple : suppression par lots
SET @last_id = 0;
WHILE 1 DO
  DELETE FROM events
  WHERE id > @last_id
  ORDER BY id
  LIMIT 1000;
  SET @rows = ROW_COUNT();
  IF @rows = 0 THEN LEAVE; END IF;
  SET @last_id = (SELECT MAX(id) FROM events WHERE id <= @last_id + 1000);
END WHILE;

Ce modèle permet de limiter la durée des transactions, de réduire les temps de verrouillage et de laisser les autres charges de travail respirer. J'adopte une approche similaire pour les mises à jour en masse : je sélectionne d'abord les ID cibles dans un ensemble temporaire (ou via une clause LIMIT), puis j'effectue les écritures de manière ciblée et je valide rapidement.

Guide de diagnostic rapide

Lorsque les temps d'attente s'allongent, je travaille en suivant un ordre bien défini :

1. Préciser le symptôme : quelles tables, quelles requêtes, à quelle heure ?
2. Rendre les chaînes d'attente visibles : dans Performance Schema, identifier les entrées « data_locks » et « data_lock_waits » ainsi que les PID bloquants ; vérifier également l'état actuel d'InnoDB.
3. Vérifier le plan d'exécution : la requête utilise-t-elle l'index prévu ? Les prédicats sont-ils indexables ?
4. Réduire l'étendue des verrous : préciser la condition WHERE, ajouter des index, éviter les balayages de plage, restreindre les lectures avec verrouillage.
5. Réduire la durée de la transaction : supprimer les interactions et les appels externes de la transaction, réduire la taille des jeux de résultats.
6. Répéter et mesurer : après avoir apporté les modifications, observer à nouveau les pics de consommation et les comparer.

Cette approche évite de naviguer à l'aveuglette. Plutôt que d'augmenter les délais d'attente, j'élimine les causes du problème – une solution plus durable et généralement plus rapide.

Éviter les écueils opérationnels

Il y a trois points auxquels je prête particulièrement attention lors de l'exécution : premièrement, je veille à ne pas désactiver par inadvertance l'autocommit au niveau global, car cela prolonge les verrous sans que l'on s'en aperçoive. Deuxièmement, j'empêche les pools de connexions de transmettre des transactions qui détiennent déjà des verrous ouverts. Troisièmement, j’utilise les points de sauvegarde de manière ciblée pour les annulations partielles, mais je ne m’attends pas à ce qu’ils raccourcissent les durées de verrouillage : le verrou reste en place jusqu’au commit ou au rollback. Une discipline rigoureuse au niveau de l’application se traduit ici directement par des temps d’attente plus courts.

En bref : les principaux enseignements

Le verrouillage par ligne garantit la cohérence des données, mais seulement lorsqu'il est associé à MVCC, avec un niveau d'isolation adapté et une conception d'index soignée, il déploie tout son potentiel. Je veille à ce que les transactions restent courtes, j'effectue un filtrage ciblé et je n'utilise FOR UPDATE que lorsque la réservation est réellement nécessaire d'un point de vue métier. Je réduis les conflits grâce à des séquences d'accès cohérentes et à des tentatives de reprise claires en cas de blocages. Je choisis les niveaux d'isolation en fonction de chaque cas d'utilisation et j'observe l'impact des verrous Gap et Next-Key. En procédant de manière mesurée et en affinant régulièrement les réglages, on atteint un haut niveau de Concurrence sans surprise.

Au final, trois éléments sont essentiels : des objets de verrouillage de petite taille, des durées de verrouillage courtes et des chemins de requête traçables. Grâce à ces principes, les charges de travail MySQL fonctionnent de manière fiable, même lorsque de nombreux utilisateurs sont actifs simultanément. Je privilégie les tests reproductibles, les métriques pertinentes et les optimisations ciblées plutôt que les refontes majeures. Ainsi, les données restent correctes, les temps de réponse faibles et les blocages rares. C'est exactement ce qu'attend chaque équipe d'une base de données réactive Base de données.