{"id":18889,"date":"2026-04-10T08:34:12","date_gmt":"2026-04-10T06:34:12","guid":{"rendered":"https:\/\/webhosting.de\/datenbank-deadlock-detection-handling-hosting-infrastructure\/"},"modified":"2026-04-10T08:34:12","modified_gmt":"2026-04-10T06:34:12","slug":"base-de-donnees-deadlock-detection-handling-hosting-infrastructure","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/datenbank-deadlock-detection-handling-hosting-infrastructure\/","title":{"rendered":"D\u00e9tection et traitement des blocages de base de donn\u00e9es dans l'h\u00e9bergement : causes, solutions et meilleures pratiques"},"content":{"rendered":"<p>Dans les environnements d'h\u00e9bergement, les <strong>mysql deadlock<\/strong>-En effet, plusieurs clients partagent le CPU, la RAM et les E\/S, ce qui prolonge la dur\u00e9e d'activation des verrous. Je montre les causes, une d\u00e9tection rapide et une gestion robuste pour que votre application r\u00e9ponde de mani\u00e8re fiable aux pics de charge et que les transactions s'effectuent sans cha\u00eenes d'attente tenaces.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>Causes<\/strong>: Transactions longues, indices manquants, requ\u00eates N+1, niveaux d'isolation \u00e9lev\u00e9s<\/li>\n  <li><strong>Reconnaissance<\/strong>: D\u00e9tecteurs automatiques, graphe d'impasse, codes d'erreur et m\u00e9triques<\/li>\n  <li><strong>\u00c9viter<\/strong>ordre de verrouillage coh\u00e9rent, requ\u00eates courtes, isolation appropri\u00e9e<\/li>\n  <li><strong>H\u00e9bergement<\/strong>Les ressources partag\u00e9es prolongent les verrous, le pooling et les r\u00e9serves IOPS aident.<\/li>\n  <li><strong>Manutention<\/strong>Logique de reprise avec backoff, timeouts et priorit\u00e9s raisonnables<\/li>\n<\/ul>\n\n<h2>Ce qui d\u00e9clenche r\u00e9ellement les deadlocks dans l'h\u00e9bergement<\/h2>\n\n<p>A <strong>Deadlock<\/strong> se produit lorsque les transactions s'attendent cycliquement les unes les autres : A tient X et veut Y, B tient Y et veut X. Dans les environnements d'h\u00e9bergement partag\u00e9s, le CPU partag\u00e9, la RAM partag\u00e9e et les E\/S lentes allongent la dur\u00e9e des <strong>Locks<\/strong>, ce qui rend ces cycles beaucoup plus fr\u00e9quents. Les requ\u00eates non optimis\u00e9es, les index manquants et les mod\u00e8les N+1 augmentent le nombre de lignes bloqu\u00e9es et le temps pendant lequel elles sont bloqu\u00e9es. Les longues transactions qui contiennent encore des appels externes aggravent consid\u00e9rablement la situation. En cas de pics de trafic, chaque retard freine d'autres requ\u00eates, ce qui entra\u00eene des r\u00e9actions en cha\u00eene avec des temps d'attente \u00e9lev\u00e9s.<\/p>\n\n<h2>Les quatre conditions en bref<\/h2>\n\n<p>Quatre conditions doivent \u00eatre r\u00e9unies pour qu'un blocage se produise : <strong>R\u00e9ciprocit\u00e9<\/strong> Exclusion, maintien et attente, pas de retrait ainsi qu'une relation d'attente circulaire. Dans les bases de donn\u00e9es, cela signifie g\u00e9n\u00e9ralement des verrous exclusifs de ligne ou de page qu'une transaction maintient en attendant d'autres ressources. Le moteur ne retire pas ces verrous de force, c'est pourquoi la situation reste en place jusqu'\u00e0 ce qu'il d\u00e9tecte un conflit. D\u00e8s qu'une cha\u00eene circulaire A\u2192B\u2192C\u2192A se forme, personne ne peut plus continuer. Celui qui affaiblit de mani\u00e8re cibl\u00e9e ces quatre \u00e9l\u00e9ments constitutifs fait nettement baisser le taux d'impasse.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/serverraum-deadlock-handling-7841.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>D\u00e9tection des blocages et gestion automatique dans MySQL et SQL Server<\/h2>\n\n<p>MySQL et SQL Server d\u00e9tectent automatiquement les cycles et choisissent un <strong>Victimes<\/strong>, que le moteur se retourne. MySQL signale souvent le conflit avec SQLSTATE 40001, ce que je traite dans l'application comme une reprise d\u00e9clenchable. SQL Server utilise un thread de surveillance qui raccourcit fortement l'intervalle de contr\u00f4le en cas de forte contenance afin de r\u00e9agir plus rapidement. En outre, il est possible de <strong>DEADLOCK_PRIORITY<\/strong> dans SQL Server, afin que les sessions moins importantes s'effacent en premier. Dans MySQL, j'\u00e9vite les scans trop longs pour que le d\u00e9tecteur ne doive pas v\u00e9rifier inutilement de nombreux bords. Celui qui comprend la s\u00e9lection automatique de la victime construit une logique de r\u00e9p\u00e9tition propre et stabilise sensiblement le d\u00e9bit.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Moteur<\/th>\n      <th>Reconnaissance<\/th>\n      <th>Choix de la victime<\/th>\n      <th>Param\u00e8tres\/signaux utiles<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>MySQL (InnoDB)<\/td>\n      <td>Interne <strong>Cycle-Check<\/strong> sur Lock-Graph<\/td>\n      <td>R\u00e9troactivit\u00e9 bas\u00e9e sur les co\u00fbts<\/td>\n      <td>innodb_deadlock_detect, SQLSTATE 40001, PERFORMANCE_SCHEMA<\/td>\n    <\/tr>\n    <tr>\n      <td>Serveur SQL<\/td>\n      <td>Moniteur de verrouillage avec fonction dynamique <strong>Intervalle<\/strong><\/td>\n      <td>Bas\u00e9 sur les co\u00fbts et les priorit\u00e9s<\/td>\n      <td>DEADLOCK_PRIORITY, erreur 1205, \u00e9v\u00e9nements \u00e9tendus<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Strat\u00e9gies : conception des transactions, indices, isolation<\/h2>\n\n<p>Je fais des transactions courtes, je pousse <strong>Logique d'entreprise<\/strong> et les appels distants de la section critique et acc\u00e8de aux tables dans un ordre coh\u00e9rent. Absence de <strong>Indices<\/strong> et je v\u00e9rifie avec EXPLAIN si les suites de jointures et les filtres sont corrects. Dans MySQL, je r\u00e9duis les verrous Next Key lorsque les requ\u00eates de port\u00e9e n'ont pas besoin de protection suppl\u00e9mentaire et j'active READ COMMITTED lorsque cela est possible. Je planifie les facteurs de remplissage pour les tableaux \u00e0 forte \u00e9criture de mani\u00e8re \u00e0 ce que les pages fractionn\u00e9es se bloquent moins souvent. En r\u00e9duisant les scans fr\u00e9quents et en uniformisant les s\u00e9quences de verrouillage, on \u00e9vite de nombreux blocages avant m\u00eame la premi\u00e8re reprise. Je r\u00e9sume de mani\u00e8re pratique les d\u00e9tails concernant les requ\u00eates et les index : <a href=\"https:\/\/webhosting.de\/fr\/base-de-donnees-performance-requetes-index-locking-serverboost\/\">Requ\u00eates et index<\/a>.<\/p>\n\n<h2>Utiliser judicieusement la mise en cache et les read-replicas<\/h2>\n\n<p>Les caches me permettent de me d\u00e9charger <strong>Touches de raccourci<\/strong> comme les sessions, les paniers ou les drapeaux de fonctionnalit\u00e9s, afin que chaque op\u00e9ration de lecture ne d\u00e9clenche pas un verrouillage co\u00fbteux. Les r\u00e9plicas de lecture servent d'\u00e9galisateurs, mais je surveille les retards de r\u00e9plication et contr\u00f4le les parts de lecture avec prudence. Un d\u00e9calage important g\u00e9n\u00e8re une pression arri\u00e8re qui finit par peser sur la base de donn\u00e9es primaire. Un cache g\u00e9ographiquement plus proche r\u00e9duit les allers-retours et donc le temps de maintien des verrous. Un coup d'\u0153il sur les d\u00e9lais d'attente aide en cas de charge : <a href=\"https:\/\/webhosting.de\/fr\/timeout-base-de-donnees-hebergement-causes-limites-serveur-dbcheck\/\">Timeouts de base de donn\u00e9es dans l'h\u00e9bergement<\/a> montrent pourquoi des valeurs limites concert\u00e9es permettent d'\u00e9viter les pannes. En consid\u00e9rant les caches, les r\u00e9pliques et les d\u00e9lais d'attente comme un ensemble, on r\u00e9duit consid\u00e9rablement les blocages.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/besprechung_deadlock_8923.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mise en commun, gestion des ressources et retraits<\/h2>\n\n<p>Je limite le nombre d'utilisateurs simultan\u00e9s <strong>Travailleur<\/strong> sur les pools de connexion et contr\u00f4le les longueurs de file d'attente pour que l'application se d\u00e9grade de mani\u00e8re contr\u00f4l\u00e9e sous la charge. Des d\u00e9lais d'attente courts \u00e9vitent que des sessions suspendues ne lient des pools entiers. Apr\u00e8s un deadlock, j'intercepte l'erreur, j'attends un back-off qui fait trembler et je red\u00e9marre la transaction jusqu'\u00e0 la limite sup\u00e9rieure. Sur le stockage partag\u00e9, je pr\u00e9vois des r\u00e9serves d'IOPS, car un rollback lent freine le d\u00e9bit global. Les outils de limitation de la charge au niveau de la couche d'application emp\u00eachent les heures de pointe d'entra\u00eener la base de donn\u00e9es dans des conflits permanents.<\/p>\n\n<h2>Diagnostic : logs, m\u00e9triques et graphique d'impasse<\/h2>\n\n<p>Pour l'analyse des causes, je collecte <strong>Codes d'erreur<\/strong>, la latence P95, les temps d'attente des verrous et j'examine les graphiques des verrous morts. Dans MySQL, le journal des requ\u00eates lentes et PERFORMANCE_SCHEMA fournissent des indications sur les bloqueurs actuels. Le graphique montre qui retient qui, dans quel ordre les blocages ont \u00e9t\u00e9 effectu\u00e9s et quelles requ\u00eates sont trop larges. La session suppos\u00e9e victime d\u00e9tient souvent les blocages les plus longs ou fonctionne sans index appropri\u00e9. Apr\u00e8s chaque correction, je lance un bref test de charge pour v\u00e9rifier si de nouveaux goulots d'\u00e9tranglement apparaissent.<\/p>\n\n<h2>Param\u00e8tres MySQL et valeurs par d\u00e9faut utiles<\/h2>\n\n<p>Je mets <strong>innodb_lock_wait_timeout<\/strong> de mani\u00e8re \u00e0 ce que les sessions bloqu\u00e9es \u00e9chouent \u00e0 temps, avant qu'elles ne lient les travailleurs. Je laisse la fonction innodb_deadlock_detect activ\u00e9e, mais je r\u00e9duis la contention en am\u00e9liorant les index et en r\u00e9duisant les lots si le d\u00e9tecteur consomme beaucoup de CPU. Des d\u00e9lais d'attente uniformes le long du chemin des requ\u00eates emp\u00eachent des situations d'attente contradictoires. Dans SQL Server, j'utilise DEADLOCK_PRIORITY et LOCK_TIMEOUT de mani\u00e8re cibl\u00e9e pour les t\u00e2ches conflictuelles. De petites adaptations cibl\u00e9es sur la base de valeurs mesur\u00e9es donnent de meilleurs r\u00e9sultats que de grands tweaks g\u00e9n\u00e9ralis\u00e9s.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/deadlock-detection-handling-blog-9273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>R\u00e9alit\u00e9 de l'h\u00e9bergement : particularit\u00e9s sur les serveurs partag\u00e9s<\/h2>\n\n<p>Les h\u00f4tes partag\u00e9s prolongent le temps de r\u00e9tention de <strong>Verrouiller<\/strong>, car les tranches de CPU, l'allocation de RAM et les E\/S sont en concurrence. Les caches masquent certaines faiblesses pendant le fonctionnement quotidien, mais ils r\u00e9v\u00e8lent les pics de charge soudains. Des plug-ins mal con\u00e7us et des index manquants augmentent le nombre de lignes bloqu\u00e9es et entra\u00eenent des blocages en s\u00e9rie. Ceux qui planifient le trafic r\u00e9servent des capacit\u00e9s et testent des sc\u00e9narios de soir\u00e9e avec Lasttools. J'ai r\u00e9uni ici des informations concr\u00e8tes sur les blocages dans l'h\u00e9bergement : <a href=\"https:\/\/webhosting.de\/fr\/base-de-donnees-deadlocks-hebergement-locktest-serverboost\/\">Deadlocks dans l'h\u00e9bergement<\/a>.<\/p>\n\n<h2>\u00c9viter les anti-patterns, choisir de meilleurs mod\u00e8les<\/h2>\n\n<p>Largeur <strong>S\u00c9LECTIONNER ... POUR LA MISE \u00c0 JOUR<\/strong> sans clause WHERE \u00e9troite bloquent trop de lignes et g\u00e9n\u00e8rent une concurrence f\u00e9roce. Les ORM avec des acc\u00e8s N+1 ou des UPDATE inutiles aggravent la situation sans que l'on s'en rende compte. Pour les files d'attente, je mise sur une paire d'index (status, created_at) et je travaille par petits lots au lieu d'utiliser MIN(id) sans index correspondant. Les tables \"append-only\" n\u00e9cessitent un pruning r\u00e9gulier et un partitionnement pour que la maintenance ne verrouille pas sur de grandes tables. Des s\u00e9quences de verrouillage claires et des transactions courtes constituent l'habitude quotidienne qui permet de limiter les blocages.<\/p>\n\n<h2>Logique commerciale id\u00e9ale et retours s\u00e9curis\u00e9s<\/h2>\n\n<p>Les retraites ne sont r\u00e9sistantes que si la r\u00e9alisation <strong>idempotent<\/strong> c'est . J'attribue un ID de requ\u00eate unique par transaction et je l'enregistre dans une colonne ou un tableau de journal d\u00e9di\u00e9. Une deuxi\u00e8me tentative reconna\u00eet l'ID d\u00e9j\u00e0 trait\u00e9 et saute l'effet de page. Pour les op\u00e9rations d'\u00e9criture, j'utilise <strong>UPSERT<\/strong>-(par exemple, INSERT ... ON DUPLICATE KEY UPDATE ou MERGE dans SQL Server) et encapsule les effets secondaires (par exemple, les e-mails, les h\u00f4tes web) en dehors de la transaction ou les rend \u00e9galement idempotents.<\/p>\n\n<pre><code>\/\/ pseudocode : Retry avec backoff tremblant + puissance d'id\u00e9ation\nmaxAttempts = 5\nfor attempt in 1..maxAttempts {\n  try {\n    beginTx()\n    ensureIdempotencyKey(requestId) \/\/ contrainte unique\n    \/\/ ... modifications all\u00e9g\u00e9es, bas\u00e9es sur les index ...\n    commit()\n    break\n  } catch (Deadlock|SerializationError e) {\n    rollback()\n    if (attempt == maxAttempts) throw e\n    sleep(jitteredBackoff(attempt)) \/\/ 50-500ms, avec jitter\n  }\n}\n<\/code><\/pre>\n\n<p>En outre, je limite les concurrents de mani\u00e8re cibl\u00e9e : Je traite les Hot-Keys en s\u00e9rie (par Mutex\/Advisory Lock) ou je r\u00e9partis la charge via des Hash-Buckets. Ainsi, les retries ne r\u00e9duisent pas seulement les erreurs, mais aussi la charge cons\u00e9cutive.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/deadlock_detection_techoffice_4523.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Le versionnement des rangs et les modes d'isolation en d\u00e9tail<\/h2>\n\n<p>Dans MySQL, bloquer sous <strong>LECTURE R\u00c9P\u00c9TABLE<\/strong> Next-Key-Locks ne se limitent pas aux lignes concern\u00e9es, mais aussi aux trous dans l'index. Cela prot\u00e8ge contre les lectures fant\u00f4mes, mais augmente la probabilit\u00e9 de blocage lors des scans de plage. Lorsque c'est possible, je place <strong>READ COMMITTED<\/strong> pour r\u00e9duire les gap locks et reformuler les requ\u00eates pour qu'elles rencontrent s\u00e9lectivement les pr\u00e9fixes d'index. Dans SQL Server, les <strong>READ COMMITTED SNAPSHOT<\/strong> (RCSI) et <strong>SNAPSHOT<\/strong> Lecture bas\u00e9e sur MVCC sans blocage de lecture ; les conflits d'\u00e9criture demeurent, mais les blocages se font plus rares. Je garde un \u0153il sur Tempdb\/Version Store pour que le versionnement des rang\u00e9es ne devienne pas un nouveau goulot d'\u00e9tranglement.<\/p>\n\n<p>Pour les compteurs, l'inventaire et les soldes de compte, je place des mises \u00e0 jour claires et br\u00e8ves sur les cl\u00e9s primaires. Je d\u00e9place les calculs complexes avant ou apr\u00e8s la transaction. Il est essentiel que chaque transaction touche le moins possible et bloque dans un ordre coh\u00e9rent.<\/p>\n\n<h2>D\u00e9samorcer les zones sensibles : Mod\u00e8le de donn\u00e9es et sharding<\/h2>\n\n<p>De nombreux blocages se produisent au niveau <strong>Points chauds<\/strong>: compteurs globaux, lignes d'\u00e9tat centralis\u00e9es, identifiants monotones. Je r\u00e9partis la charge avec un hachage ou un partitionnement temporel (par ex. par client, par jour) et j'\u00e9vite les singletons. Pour MySQL, je v\u00e9rifie <strong>innodb_autoinc_lock_mode<\/strong>Interleaved (2) r\u00e9duit la contention d'auto-incr\u00e9ment lors d'INSERTs parall\u00e8les. Pour les s\u00e9quences ou les num\u00e9ros de ticket, j'utilise des blocs pr\u00e9-allou\u00e9s par worker, afin que chaque attribution ne verrouille pas une table centrale.<\/p>\n\n<p>Le choix de la cl\u00e9 compte \u00e9galement : Les cl\u00e9s primaires composites qui refl\u00e8tent la dimension naturelle de l'acc\u00e8s (par ex. account_id + id) conduisent \u00e0 des blocages \u00e9troits et bien cibl\u00e9s. Les UUID larges sont acceptables s'ils sont randomis\u00e9s et si les splits d'index restent supportables.<\/p>\n\n<h2>Batchs, conception de t\u00e2ches et SKIP LOCKED<\/h2>\n\n<p>Je planifie les jobs d'arri\u00e8re-plan dans <strong>petits lots<\/strong> (par ex. 100-500 lignes) et utiliser un tri stable via la cl\u00e9 primaire. Dans MySQL 8.0, cela aide <strong>NOWAIT\/SKIP LOCKED<\/strong>, Je pense qu'il est pr\u00e9f\u00e9rable d'ignorer les lignes bloquantes plut\u00f4t que d'accumuler les files d'attente. Dans SQL Server, je place <strong>READPAST<\/strong> avec <strong>UPDLOCK<\/strong> et <strong>ROWLOCK<\/strong> pour faire de m\u00eame.<\/p>\n\n<pre><code>-- MySQL : tirer des t\u00e2ches sans les bloquer\nSELECT id FROM jobs\n WHERE status = 'ready' (pr\u00eat)\n ORDER BY id\n LIMIT 200\n FOR UPDATE SKIP LOCKED ;\n\n-- SQL Server : Mod\u00e8le similaire\nSELECT TOP (200) id FROM jobs WITH (ROWLOCK, UPDLOCK, READPAST)\n WHERE status = 'ready'.\n ORDER BY id ;\n<\/code><\/pre>\n\n<p>Je d\u00e9compose les grandes op\u00e9rations de maintenance monolithiques en \u00e9tapes pouvant \u00eatre reprises. Ainsi, le temps de maintien du verrouillage diminue et le paysage des t\u00e2ches reste robuste m\u00eame lors des red\u00e9marrages.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/datenbank_deadlock_8736.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Strat\u00e9gies de migration et de DDL sans temps mort<\/h2>\n\n<p>Les modifications de sch\u00e9ma peuvent d\u00e9clencher des blocages gigantesques. Dans MySQL, je fais attention \u00e0 <strong>ALGORITHM=INPLACE<\/strong> et <strong>LOCK=NONE<\/strong>, Je migre les colonnes en deux \u00e9tapes (cr\u00e9ation, remplissage, basculement). Dans SQL Server, j'utilise <strong>ONLINE=ON<\/strong> (Enterprise) et, le cas \u00e9ch\u00e9ant. <strong>WAIT_AT_LOW_PRIORITY<\/strong>, pour que le trafic de lecture\/\u00e9criture se poursuive. Je mets en attente les DDL de longue dur\u00e9e, je les mets en pause en cas de pic de charge et je les reprends de mani\u00e8re contr\u00f4l\u00e9e. Avant chaque migration, j'\u00e9tablis un plan B (chemin de retour) et je mesure les co\u00fbts d'E\/S pr\u00e9vus sur une copie.<\/p>\n\n<p>J'ajoute des index de mani\u00e8re cibl\u00e9e : d'abord pour les conditions de filtrage fr\u00e9quentes, ensuite pour les cl\u00e9s JOIN. Chaque index suppl\u00e9mentaire co\u00fbte du temps d'\u00e9criture - trop d'index rallongent les transactions et augmentent ainsi le risque d'impasse et les besoins en m\u00e9moire.<\/p>\n\n<h2>Tester et reproduire les deadlocks<\/h2>\n\n<p>Pour le d\u00e9bogage, je construis au minimum <strong>reproductible<\/strong> Sc\u00e9narios avec deux sessions : la session A bloque la ligne X et acc\u00e8de ensuite \u00e0 Y, la session B fait l'inverse. Avec des SLEEPS courts entre les d\u00e9clarations, je force la collision. C'est ainsi que je valide des hypoth\u00e8ses \u00e0 partir du graphique deadlock. Dans MySQL, j'observe parall\u00e8lement PERFORMANCE_SCHEMA (events_transactions_current, data_locks), dans SQL Server les Extended Events correspondants. Ensuite, je fais varier les index, les filtres et les ordres jusqu'\u00e0 ce que le blocage disparaisse.<\/p>\n\n<p>De tels tests font partie de la CI : les petits pics de charge qui m\u00e9langent les ex\u00e9cutions par lots et les graphiques en ligne permettent de d\u00e9tecter rapidement les erreurs de s\u00e9quence de verrouillage. Important : utiliser les m\u00eames valeurs de pool et de timeout qu'en production, sinon on passe \u00e0 c\u00f4t\u00e9 du vrai probl\u00e8me.<\/p>\n\n<h2>Observabilit\u00e9 et alerte : du signal \u00e0 l'action<\/h2>\n\n<p>Je dirige un petit nombre de <strong>Signaux<\/strong> \u00e0 partir de : Deadlocks\/minute, temps d'attente de verrouillage P95\/P99, pourcentage de transactions r\u00e9cup\u00e9r\u00e9es, ainsi que commit duration P95. Je d\u00e9clenche des alertes lorsque les m\u00e9triques sont \u00e9lev\u00e9es sur une p\u00e9riode (par ex. &gt;5 deadlocks\/min sur 10 minutes) et avec le contexte : quelles tables, quelles requ\u00eates, quels d\u00e9ploiements \u00e9taient en cours. Je s\u00e9pare les tableaux de bord en fonction des chemins de lecture\/d'\u00e9criture ; les cartes de chaleur montrent quand la plupart des conflits se produisent (heure, fen\u00eatre de traitement par lots).<\/p>\n\n<p>Pour l'action imm\u00e9diate, je d\u00e9finis <strong>Runbooks<\/strong>Abaisser les limites du pool, mettre en pause les jobs de traitement par lots d\u00e9fectueux, augmenter temporairement le TTL du cache, transf\u00e9rer la charge de lecture sur les r\u00e9plicas, lisser les fen\u00eatres d'\u00e9criture. Vient ensuite le travail sur les causes : compl\u00e9ter l'index, reconstruire la requ\u00eate, d\u00e9samorcer le mod\u00e8le de donn\u00e9es, adapter le niveau d'isolation.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/hosting-serverraum-5743.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bref et clair : comment garder les deadlocks petits<\/h2>\n\n<p>Je donne la priorit\u00e9 aux courts <strong>Transactions<\/strong>, Des s\u00e9quences de verrouillage coh\u00e9rentes et des niveaux d'isolation adapt\u00e9s permettent de lib\u00e9rer rapidement les verrous. Des index propres et des requ\u00eates l\u00e9g\u00e8res r\u00e9duisent la dur\u00e9e de chaque phase critique. Les caches et les read-replicas soulagent la base de donn\u00e9es primaire si je garde un \u0153il sur les retards de r\u00e9plication. Le pooling de connexions, les d\u00e9lais d'attente et une logique de reprise avec backoff veillent \u00e0 ce que les conflits isol\u00e9s n'interrompent pas le flux. Un monitoring continu avec un graphique d'impasse, un P95 et une attente de verrouillage permet de d\u00e9tecter rapidement les \u00e9carts, de sorte que je peux prendre des mesures correctives avant que les utilisateurs ne remarquent quoi que ce soit.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guide complet sur mysql deadlock detection et database locking issues dans l'h\u00e9bergement. Strat\u00e9gies, diagnostics et gestion pour des bases de donn\u00e9es stables.<\/p>","protected":false},"author":1,"featured_media":18882,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-18889","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"462","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"mysql deadlock","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"18882","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18889","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=18889"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18889\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/18882"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=18889"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=18889"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=18889"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}