{"id":17408,"date":"2026-02-06T18:21:51","date_gmt":"2026-02-06T17:21:51","guid":{"rendered":"https:\/\/webhosting.de\/datenbank-performance-abfragen-indizes-locking-serverboost\/"},"modified":"2026-02-06T18:21:51","modified_gmt":"2026-02-06T17:21:51","slug":"base-de-donnees-performance-requetes-index-locking-serverboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/datenbank-performance-abfragen-indizes-locking-serverboost\/","title":{"rendered":"Performance de la base de donn\u00e9es dans l'h\u00e9bergement web : requ\u00eates, index et verrouillage"},"content":{"rendered":"<p>Je vais vous montrer comment <strong>Performance de la base de donn\u00e9es<\/strong> dans l'h\u00e9bergement web : avec des requ\u00eates focalis\u00e9es, des index cibl\u00e9s et un verrouillage propre. Vous soulagez ainsi MySQL sous charge, \u00e9vitez les temps d'attente et obtenez des temps de r\u00e9ponse fiables m\u00eame en cas de nombreux acc\u00e8s simultan\u00e9s.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>Requ\u00eates<\/strong> rester mince : Projection, Filtre, EXPLAIN<\/li>\n  <li><strong>Indices<\/strong> d\u00e9finir de mani\u00e8re cibl\u00e9e : WHERE, JOIN, ORDER BY<\/li>\n  <li><strong>Verrouillage<\/strong> minimiser les risques : Row-Locks, transactions courtes<\/li>\n  <li><strong>Mise en cache<\/strong> utilisent : Redis\/Memcached, pagination des keysets<\/li>\n  <li><strong>Suivi<\/strong> \u00e9tablir des proc\u00e9dures : Slow-Log, sch\u00e9ma de performance<\/li>\n<\/ul>\n\n<h2>Sch\u00e9ma et ressources dans l'h\u00e9bergement web : les vis de r\u00e9glage<\/h2>\n\n<p>Un projet bien pens\u00e9 <strong>Conception de sch\u00e9mas<\/strong> permet d'\u00e9conomiser du temps sur le serveur en \u00e9vitant les jointures et les doublons de donn\u00e9es inutiles, sans pour autant sacrifier la lisibilit\u00e9 des requ\u00eates. Je normalise les tables jusqu'\u00e0 un niveau raisonnable et les d\u00e9normalise de mani\u00e8re cibl\u00e9e lorsque les valeurs de mesure montrent que les jointures sont trop co\u00fbteuses. Sur les h\u00f4tes de partage et de gestion, je fais attention aux profils CPU, RAM et I\/O, car les goulots d'\u00e9tranglement ne se trouvent souvent pas dans le SQL, mais dans des ressources limit\u00e9es. Pour InnoDB, je place le <strong>innodb_buffer_pool_size<\/strong> typiquement \u00e0 70-80% de la RAM disponible, afin de garder le plus de pages possible en m\u00e9moire. En outre, je v\u00e9rifie si les tables temporaires tiennent dans la m\u00e9moire, afin que les requ\u00eates ne bloquent pas des supports de donn\u00e9es lents.<\/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\/02\/datenbank-serverperformance-9472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mod\u00e8le de donn\u00e9es et types : Base pour un acc\u00e8s rapide<\/h2>\n\n<p>Je choisis <strong>Types de donn\u00e9es<\/strong> aussi petit et adapt\u00e9 que possible : INT au lieu de BIGINT, DECIMAL pour les valeurs mon\u00e9taires, DATETIME au lieu de TEXT pour les donn\u00e9es temporelles. Pour les cha\u00eenes de caract\u00e8res, je mise syst\u00e9matiquement sur <strong>utf8mb4<\/strong> avec une collation appropri\u00e9e (par exemple _ai_ci pour les comparaisons ind\u00e9pendantes de l'accent et des majuscules\/minuscules). Lorsque des comparaisons sensibles \u00e0 la casse ou binaires sont n\u00e9cessaires, j'utilise de mani\u00e8re cibl\u00e9e des collations _bin au niveau des colonnes. Ces d\u00e9cisions influencent la taille de l'index, le comportement de tri et, en fin de compte, la quantit\u00e9 de donn\u00e9es qui peut \u00eatre plac\u00e9e dans le buffer pool.<\/p>\n\n<p>\u00c0 l'adresse suivante : <strong>Cl\u00e9 primaire<\/strong> je garde la cl\u00e9 l\u00e9g\u00e8re (g\u00e9n\u00e9ralement AUTO_INCREMENT INT\/BIGINT). Comme les index secondaires d'InnoDB contiennent le PK comme suffixe, un PK compact \u00e9conomise de la m\u00e9moire et acc\u00e9l\u00e8re les scans index-only. Les CP \u00e0 croissance monotone r\u00e9duisent en outre les Page-Splits lors de l'insertion. Pour les tables tr\u00e8s charg\u00e9es en \u00e9criture avec des analyses bas\u00e9es sur le temps, j'utilise des index secondaires sur created_at ou status+created_at pour servir les requ\u00eates typiques sans frais de tri.<\/p>\n\n<p>Pour <strong>JSON<\/strong>-Je cr\u00e9e des colonnes g\u00e9n\u00e9r\u00e9es (GENERATED) qui extraient des parties cibl\u00e9es du JSON. Je peux indexer ces colonnes g\u00e9n\u00e9r\u00e9es comme des colonnes normales, de sorte que les filtres sur les chemins JSON sont bas\u00e9s sur l'index. Je repr\u00e9sente \u00e9galement les valeurs d\u00e9riv\u00e9es (par exemple LOWER(email)) comme des colonnes virtuelles au lieu d'utiliser des fonctions dans WHERE - les requ\u00eates restent ainsi sargables.<\/p>\n\n<h2>Concevoir des requ\u00eates de mani\u00e8re efficace : EXPLAIN, filtre, projection<\/h2>\n\n<p>Je commence toujours les optimisations \u00e0 la <strong>Consultation<\/strong>pas de SELECT-*, mais seulement les colonnes n\u00e9cessaires, afin que le r\u00e9seau et le CPU voient moins de charge. Avec EXPLAIN, je v\u00e9rifie si les index sont efficaces et si l'optimiseur utilise des index scans au lieu de full table scans. J'\u00e9cris les filtres sargable, c'est-\u00e0-dire du c\u00f4t\u00e9 des colonnes sans fonctions comme LOWER() dans WHERE, afin que les index puissent agir. En cas de latences remarquables, je renvoie souvent aux causes dans la conception de la requ\u00eate ; une bonne entr\u00e9e en mati\u00e8re est cet article sur <a href=\"https:\/\/webhosting.de\/fr\/pourquoi-la-latence-elevee-de-la-base-de-donnees-ne-provient-elle-pas-de-lhebergement-optimiseur-de-conception-de-requetes\/\">latence \u00e9lev\u00e9e de la base de donn\u00e9es<\/a>. Le journal des requ\u00eates lentes me fournit les plus gros consommateurs de temps, que je r\u00e8gle ensuite avec pr\u00e9cision \u00e0 l'aide d'EXPLAIN ANALYZE et de param\u00e8tres r\u00e9els.<\/p>\n\n<p>Je mets <strong>D\u00e9clarations pr\u00e9par\u00e9es<\/strong> avec des param\u00e8tres li\u00e9s, afin de r\u00e9duire l'effort d'analyse et de planification et de maintenir la stabilit\u00e9 du plan. Je remplace souvent les conditions OR sur diff\u00e9rentes colonnes par UNION ALL de deux requ\u00eates partielles faciles \u00e0 indexer. Lorsque cela est possible, je con\u00e7ois <strong>Requ\u00eates de couverture<\/strong>Un index appropri\u00e9 contenant toutes les colonnes s\u00e9lectionn\u00e9es permet d'\u00e9viter des recherches suppl\u00e9mentaires dans les tableaux et d'\u00e9conomiser des entr\u00e9es\/sorties. Je planifie les tris de mani\u00e8re \u00e0 ce qu'ils soient en harmonie avec l'ordre de l'index ; les filesort et les tables temporaires sont alors inutiles.<\/p>\n\n<p>Avec MySQL 8, j'utilise <strong>Fonctions de la fen\u00eatre<\/strong> cibl\u00e9es si elles remplacent des jointures ou des sous-requ\u00eates tout en restant compatibles avec les index. Pour les grandes valeurs de LIMIT, j'acc\u00e9l\u00e8re en utilisant des m\u00e9thodes de recherche (Keyset) et des curseurs stables (par ex. ORDER BY created_at, id) afin de garantir des appels de page d\u00e9terministes et reproductibles.<\/p>\n\n<h2>Joins, pagination et mise en cache au quotidien<\/h2>\n\n<p>Je pr\u00e9f\u00e8re <strong>INNER JOIN<\/strong> avant LEFT JOIN, si c'est autoris\u00e9 par le sujet, et indexer chaque colonne de jointure des deux tables. Je remplace souvent les sous-requ\u00eates par des jointures, car MySQL peut ainsi mieux les planifier et travailler avec des index. Je pr\u00e9f\u00e8re utiliser la pagination par keyset (WHERE id &gt; ? ORDER BY id LIMIT N), car les OFFSET sont co\u00fbteux avec des sauts importants. Les r\u00e9sultats qui changent rarement sont mis en cache via Redis ou Memcached, ce qui r\u00e9duit consid\u00e9rablement la charge du serveur. Je laisse le Query Cache historique d\u00e9sactiv\u00e9 en cas de nombreuses \u00e9critures, car sa charge administrative serait alors un frein.<\/p>\n\n<p>J'emp\u00eache <strong>N+1 requ\u00eates<\/strong>, En chargeant les enregistrements n\u00e9cessaires dans des lots (liste IN de taille limit\u00e9e) et en r\u00e9solvant au pr\u00e9alable les liens par des jointures appropri\u00e9es. Pour le <strong>Mise en cache<\/strong> je d\u00e9finis des r\u00e8gles d'invalidation claires : write-through pour les modifications, TTLs courts pour les zones volatiles, TTLs plus longs pour les flux et les archives. Je structure les cl\u00e9s de cache avec des parts de version (p. ex. version de sch\u00e9ma ou de filtre), afin que les d\u00e9ploiements ne touchent pas des structures obsol\u00e8tes.<\/p>\n\n<p>Pour la pagination par keyset dans les applications r\u00e9elles, j'utilise souvent <strong>curseurs compos\u00e9s<\/strong> (par ex. created_at et id) pour que les tris restent stables et index\u00e9s. Pour les crit\u00e8res souples (par ex. la pertinence), je veille \u00e0 ce que le crit\u00e8re de tri principal soit indexable et que la pertinence ne serve que de tiebreaker dans le cache ou dans un pr\u00e9-calcul.<\/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\/02\/webhosting_db_meeting_4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bien planifier les indices : du simple au composite<\/h2>\n\n<p>Un pr\u00e9cis <strong>Index<\/strong> convertit les recherches lin\u00e9aires en logarithmes : Avec 100 000 lignes, je me retrouve typiquement avec peu de comparaisons au lieu de balayages complets. Je place des index sur des colonnes qui apparaissent dans WHERE, JOIN et ORDER BY et je v\u00e9rifie avec EXPLAIN s'ils sont utilis\u00e9s. Je planifie les index composites en fonction de l'utilisation \u00e0 gauche : (A,B,C) couvre les recherches sur A, A+B et A+B+C, mais pas B+C sans A. Pour les longues cha\u00eenes, j'utilise des index pr\u00e9fixes, par exemple les 10-20 premiers octets, pour \u00e9conomiser de la m\u00e9moire et augmenter les occurrences en cache. Comment faire <a href=\"https:\/\/webhosting.de\/fr\/base-de-donnees-index-dommages-utilisation-mysql-pieges-serverboost\/\">Doser les indices<\/a> La pratique montre qu'un trop grand nombre d'index fait perdre un temps consid\u00e9rable lors des op\u00e9rations INSERT\/UPDATE\/DELETE.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Type d'index<\/th>\n      <th>Avantages<\/th>\n      <th>Inconv\u00e9nients<\/th>\n      <th>Utilisation typique<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>PRIMARY<\/strong><\/td>\n      <td>unicit\u00e9, lookups tr\u00e8s rapides<\/td>\n      <td>Pas de doublons autoris\u00e9s<\/td>\n      <td>Chaque table, cl\u00e9 de cluster pour InnoDB<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>UNIQUE<\/strong><\/td>\n      <td>\u00c9vite les doubles valeurs<\/td>\n      <td>Le travail d'\u00e9criture augmente<\/td>\n      <td>E-mail, nom d'utilisateur, slug<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>INDEX<\/strong><\/td>\n      <td>Filtres et tris flexibles<\/td>\n      <td>Co\u00fbts de stockage et d'entretien<\/td>\n      <td>Colonnes WHERE et JOIN<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>TEXTE INT\u00c9GRAL<\/strong><\/td>\n      <td>Recherche de texte bas\u00e9e sur la pertinence<\/td>\n      <td>Structure complexe, plus grande<\/td>\n      <td>Recherche dans les titres et les contenus<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Je fais attention \u00e0 <strong>Indices de couverture<\/strong>, qui contiennent toutes les colonnes n\u00e9cessaires (filtre, tri, projection). Cela permet d'obtenir des plans \u201eUsing index\u201c qui ne lisent que dans l'index. Pour les tris dans le sens descendant, j'utilise le support MySQL 8 pour les composants DESC dans les index composites afin d'\u00e9viter les balayages invers\u00e9s ou les tris suppl\u00e9mentaires.<\/p>\n\n<p>Pour exp\u00e9rimenter, j'utilise <strong>index invisibles<\/strong> une seule fois : Je rends un index invisible, j'observe les plans et les latences, puis je d\u00e9cide de le supprimer ou de le conserver - sans risque pour la charge de production. Je garde les ANALYZE TABLE r\u00e9guliers l\u00e9gers et cibl\u00e9s, afin que les statistiques soient fra\u00eeches et que l'optimiseur estime correctement les cardinalit\u00e9s.<\/p>\n\n<h2>WordPress MySQL : points chauds et corrections typiques<\/h2>\n\n<p>\u00c0 l'adresse suivante : <strong>WordPress<\/strong>-je v\u00e9rifie d'abord wp_posts et wp_postmeta, car c'est l\u00e0 que se terminent la plupart des requ\u00eates. J'indexe wp_posts.post_date lorsque les archives ou les flux sont tri\u00e9s, ainsi que wp_postmeta.meta_key pour les recherches rapides de m\u00e9tadonn\u00e9es. Pour WooCommerce, je fais attention aux requ\u00eates de commandes et de produits qui contiennent souvent des JOINs sur de nombreuses m\u00e9tas ; des index composites cibl\u00e9s aident ici. J'acc\u00e9l\u00e8re les listes d'administration co\u00fbteuses avec la pagination des keysets et le tri c\u00f4t\u00e9 serveur via des index appropri\u00e9s. En outre, j'utilise le cache d'objets et les transitions pour que les requ\u00eates r\u00e9currentes ne touchent pas constamment la base de donn\u00e9es.<\/p>\n\n<p>\u00c0 l'adresse suivante : <strong>meta_query<\/strong>-Je veille \u00e0 ce que le typage soit correct : je caste les valeurs num\u00e9riques pour que les comparaisons restent indexables. J'\u00e9vite les recherches LIKE larges avec jokers en t\u00eate ; au lieu de cela, j'enregistre les cl\u00e9s recherchables s\u00e9par\u00e9ment et je les indexe. Dans la mesure du possible, je charge pr\u00e9alablement WP_Query avec les m\u00e9tadonn\u00e9es n\u00e9cessaires afin d'\u00e9viter les mod\u00e8les N+1 dans le mod\u00e8le. J'adapte les t\u00e2ches Cron et les fr\u00e9quences Heartbeat afin d'\u00e9viter une charge de base permanente dans la zone d'administration.<\/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\/02\/datenbank-performance-webhosting-4826.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendre le verrouillage : Row-Locks, MVCC et isolation<\/h2>\n\n<p>Je minimise <strong>Verrouillage<\/strong>, J'utilise InnoDB, j'\u00e9cris des transactions courtes et je ne touche que les lignes dont j'ai vraiment besoin. Les verrous de niveau de rang\u00e9e permettent des acc\u00e8s simultan\u00e9s, tandis que les verrous de table arr\u00eatent beaucoup de choses, ce qui a une influence consid\u00e9rable sur les temps d'attente. MVCC veille \u00e0 ce que les lecteurs lisent sans \u00eatre bloqu\u00e9s, tant que je d\u00e9finis des niveaux d'isolation appropri\u00e9s comme READ COMMITTED. J'utilise SELECT ... FOR UPDATE avec parcimonie, car il peut bloquer les sessions d'\u00e9criture et g\u00e9n\u00e9rer de longues cha\u00eenes de temps d'attente. Pour des cas pratiques plus approfondis sur les blocages et les cycles, je vous renvoie \u00e0 ce guide sur les <a href=\"https:\/\/webhosting.de\/fr\/base-de-donnees-deadlocks-hebergement-locktest-serverboost\/\">Deadlocks dans l'h\u00e9bergement<\/a>.<\/p>\n\n<p>Je fais attention aux <strong>Isolation par d\u00e9faut<\/strong> REPEATABLE READ d'InnoDB et les gap locks qui en r\u00e9sultent lors des mises \u00e0 jour de la gamme. Si possible, je passe \u00e0 READ COMMITTED et je v\u00e9rifie si les fant\u00f4mes sont autoris\u00e9s par le m\u00e9tier - cela r\u00e9duit la concurrence des verrous. J'encapsule strictement les processus d'\u00e9criture, j'\u00e9vite les temps d'attente interactifs au sein des transactions et j'isole les points chauds (par ex. les compteurs) dans des tables s\u00e9par\u00e9es ou j'utilise des UPDATE atomiques avec des conditions.<\/p>\n\n<h2>Maintenir les transactions au plus juste et \u00e9viter les impasses<\/h2>\n\n<p>Je tiens <strong>Transactions<\/strong> et je d\u00e9place les \u00e9tapes de calcul intensif qui ne n\u00e9cessitent pas de verrou avant ou apr\u00e8s la partie \u00e9criture. J'effectue toujours les mises \u00e0 jour dans le m\u00eame ordre de colonne et de table afin d'\u00e9viter la formation de cycles entre les sessions. Je divise les longs lots en petits morceaux pour que les autres sessions puissent progresser entre-temps. En cas de conflits, je mise sur des tentatives de r\u00e9p\u00e9tition avec backoff au lieu de faire attendre une session pendant plusieurs minutes. Les d\u00e9lais d'attente pour les verrous et les d\u00e9clarations emp\u00eachent les files d'attente de se former sans que l'on s'en rende compte.<\/p>\n\n<p>\u00c0 l'adresse suivante : <strong>impasses<\/strong> j'\u00e9value SHOW ENGINE INNODB STATUS et les informations sur les blocages afin d'identifier les requ\u00eates impliqu\u00e9es et d'adapter les ordres d'acc\u00e8s. Un index suppl\u00e9mentaire cibl\u00e9, qui r\u00e9duit les scans de plage, r\u00e9sout souvent plus que toute augmentation des d\u00e9lais d'attente. J'enregistre les SQL concern\u00e9s ainsi que les bindings afin de pouvoir reproduire les pathologies et y rem\u00e9dier durablement.<\/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\/02\/datenbank_nacht_webhosting_8321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mise \u00e0 l'\u00e9chelle : r\u00e9plication, partitionnement, sharding<\/h2>\n\n<p>Si la charge augmente, je d\u00e9couple <strong>Acc\u00e8s en lecture<\/strong> via des r\u00e9plicas de lecture, afin que la charge d'\u00e9criture sur le serveur primaire ne ralentisse pas toute l'application. Les caches sont plac\u00e9s avant les r\u00e9plicas afin que chaque demande ne soit pas envoy\u00e9e \u00e0 la base de donn\u00e9es. Je divise les grandes tables \u00e0 croissance historique par partitionnement par date ou par hachage, ce qui rend la maintenance et les analyses plus pr\u00e9visibles. Lorsqu'un n\u0153ud individuel atteint ses limites, j'envisage le sharding par domaine sp\u00e9cialis\u00e9. Il reste important que l'application et les pilotes g\u00e8rent l'entrep\u00f4t de r\u00e9plication et n'utilisent que des chemins coh\u00e9rents pour les op\u00e9rations critiques.<\/p>\n\n<p>Je prends en compte <strong>Read-Your-Write<\/strong>-Les flux critiques sont lus directement depuis le serveur primaire, les chemins moins sensibles peuvent \u00eatre lus avec un certain retard depuis le r\u00e9plica. Je contr\u00f4le en permanence les m\u00e9triques de lag et, en cas de d\u00e9passement des valeurs limites, je me remets automatiquement sur le serveur primaire. Je planifie les partitions de mani\u00e8re \u00e0 ce que le pruning soit efficace (filtre sur la cl\u00e9 de partition) et j'\u00e9vite les ORDER BY globaux sur de nombreuses partitions s'il n'y a pas d'index correspondant.<\/p>\n\n<h2>Configuration du serveur : les bons param\u00e8tres<\/h2>\n\n<p>En plus du buffer pool, j'ajuste <strong>max_connections<\/strong> adapt\u00e9 au parall\u00e9lisme r\u00e9el, afin que le serveur ne g\u00e8re pas trop de threads semi-actifs. Avec thread_cache_size, j'\u00e9vite les recr\u00e9ations co\u00fbteuses de threads en cas de connexions fr\u00e9quentes. J'augmente suffisamment tmp_table_size et max_heap_table_size pour que les tables temporaires se d\u00e9placent rarement sur des supports de donn\u00e9es. Sur les syst\u00e8mes avec beaucoup de RAM, je veille \u00e0 un r\u00e9glage propre de NUMA et d'E\/S afin que la m\u00e9moire et les SSD fournissent les performances pr\u00e9vues. Je limite les logs de mani\u00e8re rotative afin que les diagnostics soient maintenus sans que les supports de stockage ne se remplissent.<\/p>\n\n<p>Dans les environnements PHP et Node, je mise sur <strong>Recours \u00e0 la connexion<\/strong> et des pools de travail limit\u00e9s : Il vaut mieux avoir peu de connexions bien utilis\u00e9es que des centaines de connexions au ralenti. Avec PHP-FPM, je r\u00e8gle pm.max_children et pm.max_requests de mani\u00e8re \u00e0 ce que MySQL ne soit pas noy\u00e9 sous des flots de connexions. Je n'utilise des connexions persistantes que si elles correspondent \u00e0 la charge et qu'il n'y a pas de risque d'overcommit - sinon, les connexions courtes et r\u00e9utilis\u00e9es avec un pooling propre sont plus robustes.<\/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\/02\/datenbankperformance_4928.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring et d\u00e9pannage : ce que je v\u00e9rifie chaque jour<\/h2>\n\n<p>Je mesure <strong>en continu<\/strong>Le journal des requ\u00eates lentes, le sch\u00e9ma de performance et les variables d'\u00e9tat me montrent les tendances avant que les utilisateurs ne ressentent les temps d'attente. Avec EXPLAIN ANALYZE, je v\u00e9rifie les temps d'ex\u00e9cution r\u00e9els des diff\u00e9rents op\u00e9rateurs et les compare aux attentes. Des outils comme pt-query-digest ou mysqltuner.pl donnent des indications sur les index, la taille des tampons et les mod\u00e8les erron\u00e9s. Chaque semaine, je v\u00e9rifie la fragmentation et j'effectue des OPTIMIZE TABLE cibl\u00e9s, l\u00e0 o\u00f9 cela apporte quelque chose de mesurable. Apr\u00e8s des modifications, je teste toujours avec des extraits de donn\u00e9es de production, afin que les optimisations portent \u00e9galement sous une cardinalit\u00e9 r\u00e9elle.<\/p>\n\n<p>Vers les <strong>M\u00e9triques de base<\/strong> Pour moi, cela comprend : le taux d'utilisation du buffer pool, Rows Examined vs. Rows Sent, Handler_read_rnd_next (proportion de Full-Scans), les tables temporaires sur disque, Threads_running, InnoDB Row Lock Time, Table_open_cache et Open_files_limit. En cas de valeurs aberrantes, j'active de mani\u00e8re cibl\u00e9e les consommateurs de sch\u00e9mas de performance et j'utilise les vues de sch\u00e9mas sys pour r\u00e9duire les hotspots jusqu'au niveau de la requ\u00eate et de l'attente.<\/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\/02\/datenbank-performance-4482.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Statistiques de l'optimiseur et stabilit\u00e9 du plan<\/h2>\n\n<p>Je tiens <strong>Statistiques<\/strong> actuel : ANALYZE TABLE en cas de modifications importantes des donn\u00e9es, et lorsque les cardinalit\u00e9s sont difficiles \u00e0 estimer, j'utilise des histogrammes (MySQL 8) pour que l'optimiseur \u00e9value correctement les pr\u00e9dicats s\u00e9lectifs. Dans le cas de plans tr\u00e8s fluctuants, je v\u00e9rifie s'il n'y a pas de malchance de liaison et je stabilise en adaptant les indices ou en reformulant l\u00e9g\u00e8rement les requ\u00eates. J'\u00e9vite les highlights durs de l'optimiseur en largeur et ne les utilise, si tant est qu'ils le fassent, que de mani\u00e8re tr\u00e8s limit\u00e9e apr\u00e8s mesure.<\/p>\n\n<h2>Changements dans l'exploitation : DDL en ligne et mod\u00e8les de migration<\/h2>\n\n<p>Je planifie les modifications de sch\u00e9ma avec <strong>ALGORITHM=INSTANT\/INPLACE<\/strong> et LOCK=NONE, lorsqu'ils sont disponibles. Cela permet d'introduire de nouvelles colonnes ou de nouveaux index en cours d'utilisation, sans interruption de la lecture\/\u00e9criture. Pour les reconstructions co\u00fbteuses, je travaille avec des tables d'ombre et des vues commutables ou des indicateurs de fonctionnalit\u00e9s. Je construis de pr\u00e9f\u00e9rence les index en dehors des fen\u00eatres de charge principales et j'observe les latences d'E\/S et de r\u00e9plication pour que les read-replicas ne soient pas distanc\u00e9s.<\/p>\n\n<h2>Op\u00e9rations en vrac et gestion des donn\u00e9es<\/h2>\n\n<p>Pour <strong>Insertions en masse<\/strong> j'utilise des INSERTs multilignes dans des lots contr\u00f4l\u00e9s, je suspends l'autocommit et je garde les transactions petites. Si cela est autoris\u00e9, LOAD DATA INFILE acc\u00e9l\u00e8re consid\u00e9rablement ; sinon, je travaille avec des d\u00e9clarations pr\u00e9par\u00e9es et des tailles de lots raisonnables. Pour les mises \u00e0 jour importantes, je proc\u00e8de de mani\u00e8re it\u00e9rative (boucles LIMIT avec un tri stable) afin de maintenir les verrouillages courts et de ne pas inonder le buffer pool. Je planifie les t\u00e2ches de maintenance (archivage, suppression d'anciennes donn\u00e9es) avec une logique de throttling prudente, afin que la charge productive ne soit pas ralentie.<\/p>\n\n<h2>Mod\u00e8les critiques et contre-mesures rapides<\/h2>\n\n<p>Si je <strong>Charge de pointe<\/strong> je limite les pages ch\u00e8res avec OFFSET et je passe \u00e0 la pagination par keyset, ce qui soulage imm\u00e9diatement. En l'absence d'indices sur des filtres fr\u00e9quents, un indice composite bien d\u00e9fini permet d\u00e9j\u00e0 de r\u00e9aliser des gains \u00e0 deux chiffres. En cas de longs verrous, je coupe les plus grosses transactions en unit\u00e9s plus petites, ce qui permet d'\u00e9couler rapidement les files d'attente. Avant les mises \u00e0 jour des plugins dans WordPress, je teste les requ\u00eates, car les nouvelles fonctionnalit\u00e9s introduisent souvent des m\u00e9tafiltres suppl\u00e9mentaires. Pour la mesurabilit\u00e9, je place Timing, Rows Examined et Rows Sent au niveau de la requ\u00eate afin de pouvoir prouver objectivement les progr\u00e8s.<\/p>\n\n<h2>En bref<\/h2>\n\n<p>Avec des <strong>Requ\u00eates<\/strong>, J'am\u00e9liore durablement les performances de la base de donn\u00e9es gr\u00e2ce \u00e0 des index adapt\u00e9s et \u00e0 un verrouillage l\u00e9ger. Je commence par la projection et les filtres, je mesure avec EXPLAIN ANALYZE et je corrige ensuite le sch\u00e9ma et les index. Je commence t\u00f4t \u00e0 utiliser les caches, j'active la r\u00e9plication lorsque les acc\u00e8s en lecture augmentent et le partitionnement stabilise les tr\u00e8s grandes tables. Je d\u00e9finis des param\u00e8tres tels que innodb_buffer_pool_size, tmp_table_size et max_connections en fonction des donn\u00e9es et non de mon instinct. En mesurant de mani\u00e8re cons\u00e9quente, en modifiant de mani\u00e8re cibl\u00e9e et en mesurant \u00e0 nouveau, on obtient des temps de r\u00e9ponse courts et une exp\u00e9rience utilisateur stable dans le domaine de l'h\u00e9bergement web.<\/p>","protected":false},"excerpt":{"rendered":"<p>Am\u00e9liorer les performances des bases de donn\u00e9es dans l'h\u00e9bergement web : optimiser les requ\u00eates, les index et le verrouillage pour mysql performance hosting et WordPress MySQL.<\/p>","protected":false},"author":1,"featured_media":17401,"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-17408","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":"1279","_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":"Datenbank-Performance","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":"17401","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/17408","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=17408"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/17408\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/17401"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=17408"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=17408"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=17408"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}