{"id":16878,"date":"2026-01-16T18:23:13","date_gmt":"2026-01-16T17:23:13","guid":{"rendered":"https:\/\/webhosting.de\/wordpress-wordpress-datenbank-indizes-leistung-boost-optimiert\/"},"modified":"2026-01-16T18:23:13","modified_gmt":"2026-01-16T17:23:13","slug":"wordpress-wordpress-base-de-donnees-indices-performance-boost-optimise","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/wordpress-wordpress-datenbank-indizes-leistung-boost-optimiert\/","title":{"rendered":"WordPress et les index de base de donn\u00e9es : Quand ils aident et quand ils n'aident pas"},"content":{"rendered":"<p>Je montre quand <strong>Index des bases de donn\u00e9es<\/strong> Les requ\u00eates WordPress acc\u00e9l\u00e8rent sensiblement et dans quels sc\u00e9narios elles d\u00e9gradent les performances. Gr\u00e2ce \u00e0 des r\u00e8gles MySQL claires, des tables WP typiques et des v\u00e9rifications \u00e9prouv\u00e9es, je d\u00e9cide si un index convient ou si de meilleurs <strong>Alternatives<\/strong> aider.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Avant de bricoler dans la base de donn\u00e9es, je d\u00e9finis clairement <strong>Objectifs<\/strong> et je mesure les valeurs r\u00e9elles. Je donne la priorit\u00e9 aux requ\u00eates bas\u00e9es sur la lecture, car c'est l\u00e0 que les indices fournissent le plus d'informations. <strong>Effet<\/strong>. Je traite les tableaux \u00e0 forte \u00e9criture avec prudence, car chaque index suppl\u00e9mentaire ralentit les op\u00e9rations d'insertion et de mise \u00e0 jour. Je laisse souvent les petits tableaux inchang\u00e9s, car leur analyse est plus rapide que la v\u00e9rification d'un tableau. <strong>Index<\/strong>. Et je combine les index avec la mise en cache afin de r\u00e9duire durablement les acc\u00e8s aux donn\u00e9es. <strong>abaisser<\/strong>.<\/p>\n<ul>\n  <li><strong>Leselast<\/strong> \u00e9tablir des priorit\u00e9s : acc\u00e9l\u00e9rer WHERE, JOIN, ORDER BY<\/li>\n  <li><strong>S\u00e9lectivit\u00e9<\/strong> v\u00e9rifier : peu de doublons valent la peine<\/li>\n  <li><strong>Overhead<\/strong> attention \u00e0 cela : L'\u00e9criture est plus lente<\/li>\n  <li><strong>wp_postmeta<\/strong> et traiter wp_options de mani\u00e8re cibl\u00e9e<\/li>\n  <li><strong>EXPLAIN<\/strong> utiliser et mesurer au lieu de deviner<\/li>\n<\/ul>\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\/01\/wordpress-datenbank-indexe-9381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comment les index fonctionnent dans MySQL et WordPress<\/h2>\n<p>Un index fonctionne comme un <strong>Table des mati\u00e8res<\/strong>Au lieu de v\u00e9rifier chaque ligne, MySQL va directement \u00e0 la zone correspondante. Les index B-Tree couvrent la plupart des cas de WordPress, car ils permettent des tris, des filtres de plages et des JOIN tr\u00e8s <strong>bien<\/strong> soutiennent la recherche. Les index de hachage acc\u00e9l\u00e8rent les comparaisons exactes, mais ne conviennent pas pour les rangs ou les requ\u00eates LIKE, ce que je vois souvent lors des recherches. Les index de texte int\u00e9gral indexent les mots et acc\u00e9l\u00e8rent consid\u00e9rablement les recherches par mots-cl\u00e9s dans les longs champs de texte comme post_content. Sans index pertinents, toute requ\u00eate complexe se termine par un balayage complet de la table, et c'est l\u00e0 que se produisent des erreurs sensibles. <strong>Temps d'attente<\/strong>.<\/p>\n\n<h2>Quand les index dans WordPress sont-ils vraiment utiles ?<\/h2>\n<p>Je place des index l\u00e0 o\u00f9 les requ\u00eates sont s\u00e9lectives et r\u00e9guli\u00e8res, par exemple sur <strong>ID<\/strong>, e-mail, slug ou post_date. Dans wp_posts, les index sur post_author, post_date et post_status sont efficaces, car ces colonnes apparaissent souvent dans WHERE et ORDER BY. Dans wp_postmeta, un index sur meta_key et optionnellement (meta_key, meta_value) fournit d'\u00e9normes sauts lorsque les th\u00e8mes ou les plugins demandent beaucoup de champs personnalis\u00e9s. Les JOINs entre wp_posts et wp_postmeta profitent sensiblement d\u00e8s que les deux pages portent les cl\u00e9s appropri\u00e9es. Et pour les grandes tables, les rapports, les archives et les pages de cat\u00e9gories sont gagnants si les requ\u00eates lisent l'index et non des millions de lignes. <strong>doivent \u00eatre<\/strong>.<\/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\/01\/wordpress_datenbank_meeting_9284.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quand les indices ne servent pas \u00e0 grand-chose ou sont m\u00eame nuisibles<\/h2>\n<p>Chaque indice suppl\u00e9mentaire co\u00fbte <strong>M\u00e9moire<\/strong> et ralentit les op\u00e9rations d'insertion, de mise \u00e0 jour et de suppression, car MySQL doit \u00e9galement g\u00e9rer la structure. Dans les tables \u00e0 \u00e9criture intensive, cela peut augmenter sensiblement le temps de fonctionnement global, m\u00eame si des lectures individuelles semblent plus rapides. Les colonnes \u00e0 faible s\u00e9lectivit\u00e9, par exemple les champs bool\u00e9ens ou quelques cat\u00e9gories, ne fournissent pas beaucoup de puissance de filtrage \u00e0 l'optimiseur. Je pr\u00e9f\u00e8re parcourir directement les tr\u00e8s petits tableaux, car les frais g\u00e9n\u00e9raux li\u00e9s \u00e0 la v\u00e9rification de l'index compensent les avantages. Je r\u00e9sume les erreurs typiques et les contre-mesures dans un guide sur l'optimisation. <a href=\"https:\/\/webhosting.de\/fr\/base-de-donnees-index-dommages-utilisation-mysql-pieges-serverboost\/\">Les pi\u00e8ges de l'index MySQL<\/a> que j'ai demand\u00e9 avant toute modification. <strong>utilise<\/strong>.<\/p>\n\n<h2>Mise en \u0153uvre pratique : de la mesure au changement<\/h2>\n<p>Je commence par mesurer, pas par <strong>Sens du ventre<\/strong>Query Monitor dans le backend de WordPress me montre les requ\u00eates lentes, les param\u00e8tres et les appelants. EXPLAIN me dit si MySQL utilise un index ou s'il scanne la table enti\u00e8re via ALL ; je le vois au type, key et rows. Sur la base de ces donn\u00e9es, je con\u00e7ois des index cibl\u00e9s pour les colonnes dans WHERE, JOIN et ORDER BY, plut\u00f4t que d'indexer \u201eau cas o\u00f9\u201c. Apr\u00e8s chaque modification, je mesure \u00e0 nouveau et j'enregistre l'historique des modifications afin d'\u00e9liminer rapidement les effets n\u00e9gatifs. Si les temps d'attente sont principalement dus \u00e0 la conception de la requ\u00eate, j'utilise la valeur <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\/\">Conception de requ\u00eates au lieu de mat\u00e9riel<\/a>, car les serveurs plus puissants ne font que masquer <strong>Causes<\/strong>.<\/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\/01\/wordpress-datenbank-indizes-vergleich-8271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Indexer les tableaux WordPress de mani\u00e8re cibl\u00e9e : Aper\u00e7u et exemples<\/h2>\n<p>Dans wp_posts, j'acc\u00e9l\u00e8re les requ\u00eates sur les archives, les auteurs ou les statuts avec des index sur <strong>post_date<\/strong>, post_author, post_status et \u00e9ventuellement des combinaisons de ceux-ci. Dans wp_postmeta, je mets meta_key et, si n\u00e9cessaire, (post_id, meta_key) ou (meta_key, meta_value), selon que je filtre plus souvent des cl\u00e9s ou des valeurs. Dans wp_comments, un index sur comment_post_ID agit pour acc\u00e9l\u00e9rer les listes de commentaires par post. Dans wp_users, les index sur user_email et user_login fournissent un acc\u00e8s rapide pour les logins ou les recherches d'admin. Et dans les tableaux de taxinomie, je fais attention aux chemins JOIN pour que les requ\u00eates sur les cat\u00e9gories, les tags et les attributs de produits soient aussi efficaces que possible. <strong>directement<\/strong> travailler.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Tableau WP \/ champ<\/th>\n      <th>Filtre typique<\/th>\n      <th>Recommandation de l'indice<\/th>\n      <th>Avantages<\/th>\n      <th>Risque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>wp_posts (post_date, post_status)<\/td>\n      <td>Archives, listes d'\u00e9tat<\/td>\n      <td>INDEX(statut_post, date_post)<\/td>\n      <td>Tri et rangs rapides<\/td>\n      <td>Plus d'overhead d'\u00e9criture<\/td>\n    <\/tr>\n    <tr>\n      <td>wp_posts (post_author)<\/td>\n      <td>Pages d'auteur<\/td>\n      <td>INDEX(post_author)<\/td>\n      <td>Filtration rapide<\/td>\n      <td>Faible b\u00e9n\u00e9fice pour les petits sites<\/td>\n    <\/tr>\n    <tr>\n      <td>wp_postmeta (meta_key, meta_value)<\/td>\n      <td>Champs personnalis\u00e9s<\/td>\n      <td>INDEX(meta_key), le cas \u00e9ch\u00e9ant (meta_key, meta_value)<\/td>\n      <td>Une nette acc\u00e9l\u00e9ration<\/td>\n      <td>Besoin de m\u00e9moire plus important<\/td>\n    <\/tr>\n    <tr>\n      <td>wp_comments (comment_post_ID)<\/td>\n      <td>Commentaires par article<\/td>\n      <td>INDEX(comment_post_ID)<\/td>\n      <td>Attribution rapide<\/td>\n      <td>Plus de travail de mise \u00e0 jour<\/td>\n    <\/tr>\n    <tr>\n      <td>wp_users (user_email, user_login)<\/td>\n      <td>Login, recherche d'admin<\/td>\n      <td>UNIQUE(user_email), INDEX(user_login)<\/td>\n      <td>Matches exacts<\/td>\n      <td>Frais d'\u00e9criture pour les importations en masse<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>J'utilise \u00e9galement des index de pr\u00e9fixe pour les longues cha\u00eenes, par exemple <strong>meta_key<\/strong>(20) afin de limiter l'espace n\u00e9cessaire et l'empreinte du cache. J'aligne les index \u00e0 plusieurs colonnes sur l'ordre de filtrage dans les requ\u00eates afin que le pr\u00e9fixe de gauche soit utilis\u00e9. Pour les recherches de texte \u00e0 partir d'un volume moyen, un index plein texte sur post_content fournit des temps de r\u00e9ponse nettement plus courts. Pour les recherches LIKE avec le caract\u00e8re g\u00e9n\u00e9rique principal (c), je replanifie, car aucun index classique ne peut aider. Et avant de modifier les tables, je sauvegarde la base de donn\u00e9es et teste les modifications dans un <strong>Staging<\/strong>-environnement.<\/p>\n\n<h2>Mesure et contr\u00f4le : EXPLAIN, SHOW INDEX et logs<\/h2>\n<p>Avec EXPLAIN, je vois d'un coup d'\u0153il si une requ\u00eate correspond au <strong>Index<\/strong> utilise : type=ref ou range est bon, ALL indique un balayage de la table. SHOW INDEX FROM table r\u00e9v\u00e8le les index existants, la cardinalit\u00e9 et les doublons, que je supprime syst\u00e9matiquement. J'\u00e9cris activement le slow_query_log dans my.cnf afin de rassembler les requ\u00eates \u00e0 longue dur\u00e9e d'ex\u00e9cution et de les traiter de mani\u00e8re cibl\u00e9e. Apr\u00e8s des modifications, j'utilise OPTIMIZE TABLE pour mettre \u00e0 jour les statistiques et la fragmentation. Et je documente les modifications avec un commentaire et la date directement dans le <strong>SQL<\/strong>-pour que je puisse les reproduire plus tard.<\/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\/01\/wordpress_datenbank_indizes_4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>WooCommerce, wp_postmeta et texte int\u00e9gral : optimiser en pratique<\/h2>\n<p>Les boutiques proposant de nombreux produits souffrent souvent de nombreux <strong>JOINs<\/strong> via wp_postmeta, car les propri\u00e9t\u00e9s et les filtres s'y trouvent. Les index sur (post_id, meta_key) acc\u00e9l\u00e8rent de mani\u00e8re mesurable les pages de produits, les filtres et les appels API. Pour les pages de cat\u00e9gories, une combinaison d'index et de mise en cache est importante afin que les listes r\u00e9currentes ne surchargent pas constamment la base de donn\u00e9es. Pour les recherches de produits, un index plein texte sur le titre et le contenu peut \u00eatre utile, mais je teste d'abord les mots d'arr\u00eat, la longueur minimale des mots et la pertinence. Si les filtres misent fortement sur meta_value, j'examine la structure des donn\u00e9es ou je stocke les valeurs r\u00e9p\u00e9titives dans des tables normalis\u00e9es avec des <strong>Cl\u00e9s<\/strong> de.<\/p>\n\n<h2>wp_options nettoyer : Autoload et Transients<\/h2>\n<p>Le tableau wp_options est souvent utilis\u00e9 pour le <strong>goulot de bouteille<\/strong>, lorsque les entr\u00e9es autoload se d\u00e9veloppent de mani\u00e8re incontr\u00f4l\u00e9e. Je minimise autoload=yes au strict n\u00e9cessaire et supprime les anciens transients pour que WordPress lise moins de m\u00e9moire au d\u00e9marrage. Un index suppl\u00e9mentaire y est moins souvent utile qu'un entretien cons\u00e9quent des donn\u00e9es et une mise en cache judicieuse. Pour une entr\u00e9e en mati\u00e8re structur\u00e9e, j'utilise ce guide pour <a href=\"https:\/\/webhosting.de\/fr\/wordpress-optimiser-la-base-de-donnees-wpoptions-conseils-gestion-des-donnees\/\">optimiser wp_options<\/a> et je contr\u00f4le ensuite r\u00e9guli\u00e8rement le volume. Si n\u00e9cessaire, je d\u00e9place les options rarement utilis\u00e9es dans des tableaux s\u00e9par\u00e9s ou je les r\u00e9duis par le biais d'options planifi\u00e9es. <strong>Travaux de nettoyage<\/strong>.<\/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\/01\/wordpress_datenbank_index_7495.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Choisir correctement les index multi-colonnes, pr\u00e9fixes et \u201ecovering\u201c.<\/h2>\n<p>Je choisis l'ordre des colonnes dans l'index multi-colonnes en fonction du nombre r\u00e9el de colonnes. <strong>Filtrage<\/strong> dans le WHERE, pas au feeling. La partie principale de l'index doit porter la restriction la plus forte pour que la recherche s\u00e9lective soit efficace. Pour les tris, l'utilit\u00e9 d\u00e9pend du fait que les colonnes de tri se trouvent \u00e0 l'endroit appropri\u00e9 dans l'index et que le sens est compatible. Les index de couverture, qui contiennent toutes les colonnes n\u00e9cessaires d'une requ\u00eate, \u00e9vitent des acc\u00e8s suppl\u00e9mentaires \u00e0 la table et r\u00e9duisent sensiblement les latences. Et les index de pr\u00e9fixe sur des cha\u00eenes de caract\u00e8res variables me permettent de r\u00e9duire la m\u00e9moire et de pr\u00e9server le buffer pool. <strong>efficace<\/strong>.<\/p>\n\n<h2>Questions d'architecture : mise en cache, mise en commun et param\u00e8tres du serveur<\/h2>\n<p>Les indices sont plus efficaces lorsque je les utilise avec un <strong>Objet<\/strong>-(par exemple Redis) afin d'\u00e9viter les requ\u00eates r\u00e9p\u00e9titives. Une gestion persistante des connexions et des param\u00e8tres de mise en pool propres r\u00e9duisent les temps de construction pour les travailleurs PHP. J'optimise les param\u00e8tres InnoDB tels que innodb_buffer_pool_size, afin que les pages d'index et de donn\u00e9es fr\u00e9quemment utilis\u00e9es soient en m\u00e9moire. Tout aussi important : quelques requ\u00eates bien con\u00e7ues au lieu de nombreuses petites, afin de ma\u00eetriser l'overhead par requ\u00eate. Et avant de mettre \u00e0 niveau le mat\u00e9riel, je v\u00e9rifie le plan de requ\u00eate, la couverture de l'index et la logique de l'application, car ce sont les \u00e9l\u00e9ments les plus importants. <strong>Levier<\/strong> offrir.<\/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\/01\/wordpress-datenbankindizes-9381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Indexer correctement les mod\u00e8les de requ\u00eates WP fr\u00e9quents<\/h2>\n<p>Les requ\u00eates typiques de WordPress suivent des sch\u00e9mas r\u00e9p\u00e9titifs. Je v\u00e9rifie syst\u00e9matiquement :<\/p>\n<ul>\n  <li>Combinaisons WHERE avec \u00e9galit\u00e9 devant domaine : dans un index, j'ordonne les colonnes de telle sorte que <strong>=<\/strong>-Conditions d'utilisation <strong>BETWEEN<\/strong>, <strong>&gt;<\/strong>, <strong>&lt;<\/strong> ou LIKE \u201aabc%\u2018. Ainsi, l'espace de recherche reste petit et l'optimiseur peut fonctionner pour la colonne Range \u201ede \u00e0\u201c dans l'index.<\/li>\n  <li>Couvrir ORDER BY avec un index : Si une requ\u00eate trie par post_date DESC pour un certain post_status, j'utilise un index compos\u00e9 comme (post_status, post_date DESC). Les versions modernes de MySQL supportent <strong>descendant<\/strong> colonnes d'index, ce qui \u00e9vite Filesort.<\/li>\n  <li>Minimiser les chemins JOIN : En JOINant wp_posts \u2192 wp_postmeta sur post_id, (post_id, meta_key) acc\u00e9l\u00e8re consid\u00e9rablement la recherche de certaines cl\u00e9s. De \u201el'autre c\u00f4t\u00e9\u201c, un index sur les colonnes filtr\u00e9es dans wp_posts (par exemple post_status) aide \u00e0 rendre les deux \u00e9tapes s\u00e9lectives.<\/li>\n  <li>EXISTS au lieu de IN pour les grandes quantit\u00e9s : Lorsque les sous-requ\u00eates fournissent de nombreuses valeurs, les variantes EXISTS s\u00e9mantiquement identiques sont souvent plus avantageuses et permettent une meilleure utilisation de l'index.<\/li>\n<\/ul>\n\n<h2>Fonctionnalit\u00e9s MySQL pour un index tuning moderne<\/h2>\n<p>Les versions actuelles de MySQL\/MariaDB offrent des fonctions que j'utilise de mani\u00e8re cibl\u00e9e :<\/p>\n<ul>\n  <li><strong>EXPLAIN ANALYZE<\/strong> montre des dur\u00e9es r\u00e9elles par \u00e9tape de plan. Je vois si le plan est adapt\u00e9 ou si les statistiques induisent l'Optimizer en erreur.<\/li>\n  <li><strong>Indices invisibles<\/strong> je l'utilise pour faire des tests : Je rends un index temporairement invisible et j'observe si les requ\u00eates sont plus lentes. De cette mani\u00e8re, je supprime du poids sans risque.<\/li>\n  <li><strong>Colonnes fonctionnelles\/g\u00e9n\u00e9r\u00e9es<\/strong>Lorsque les requ\u00eates comparent LOWER(email), je cr\u00e9e une colonne g\u00e9n\u00e9r\u00e9e avec une repr\u00e9sentation normalis\u00e9e et je l'indexe. Ainsi, l'index reste utilisable m\u00eame si le WHERE contient une fonction.<\/li>\n  <li><strong>Histogrammes et statistiques<\/strong>: En cas de distributions tr\u00e8s d\u00e9s\u00e9quilibr\u00e9es, je mets \u00e0 jour les statistiques pour que l'optimiseur \u00e9value la s\u00e9lectivit\u00e9 de mani\u00e8re r\u00e9aliste.<\/li>\n<\/ul>\n\n<h2>Modifier sans temps d'arr\u00eat : d\u00e9ployer et red\u00e9ployer en toute s\u00e9curit\u00e9<\/h2>\n<p>Je planifie les changements d'index de mani\u00e8re \u00e0 ce que le site reste en ligne. J'utilise des fen\u00eatres de migration \u00e0 faible charge, je mise sur des variantes ALTER en ligne et j'observe pendant ce temps les latences et les temps d'attente de verrouillage. Avant cela, je mesure les besoins en m\u00e9moire afin que les index suppl\u00e9mentaires ne prennent pas la place du buffer pool. Pour un rollback propre, je tiens \u00e0 disposition les scripts DROP\/CREATE et les commentaires correspondants avec la date, afin de pouvoir effectuer rapidement les modifications. <strong>retirer<\/strong> peut.<\/p>\n\n<h2>WooCommerce concr\u00e8tement : HPOS, lookups et filtres<\/h2>\n<p>Jouer dans les configurations WooCommerce modernes <strong>Tables d'ordre et de consultation<\/strong> jouent un r\u00f4le important. Je veille \u00e0 ce que les requ\u00eates sur les r\u00e9capitulatifs de commande par statut et par date portent des index appropri\u00e9s, afin que les listes d'administration et les rapports s'ouvrent rapidement. Les filtres de produits bas\u00e9s sur les attributs, les prix ou les stocks b\u00e9n\u00e9ficient de tables de recherche avec des cl\u00e9s cibl\u00e9es. Si les filtres vont durement sur meta_value, un changement de concept m'aide : normaliser les attributs fr\u00e9quemment utilis\u00e9s ou les mat\u00e9rialiser dans des tables de recherche pour all\u00e9ger le poids de wp_postmeta.<\/p>\n\n<h2>Multisite et grandes installations<\/h2>\n<p>Dans les environnements multi-sites, WordPress s'adapte \u00e0 l'aide de tableaux s\u00e9par\u00e9s par site. Ainsi, les tableaux individuels restent plus petits - ce qui est bon pour <strong>S\u00e9lectivit\u00e9<\/strong> et des occurrences de cache. J'\u00e9vite les rapports globaux sur l'ensemble des sites sans agr\u00e9gations pr\u00e9par\u00e9es. Si de nombreux sites doivent tout de m\u00eame \u00eatre regroup\u00e9s, je travaille avec des tables d'agr\u00e9gation remplies p\u00e9riodiquement et des index cibl\u00e9s sur les chemins de requ\u00eate.<\/p>\n\n<h2>Jeu de caract\u00e8res, collation et longueur d'index<\/h2>\n<p>Avec <strong>utf8mb4<\/strong> les cl\u00e9s d'index grandissent en largeur. Je pr\u00e9vois sciemment des index de pr\u00e9fixe (par exemple (meta_key(20))), afin que la limite de 3072 octets par index ne devienne pas un obstacle. Pour les recherches sensibles \u00e0 la casse, je choisis une collation appropri\u00e9e ; si je veux n\u00e9anmoins comparer de mani\u00e8re exactement normalis\u00e9e (LOWER\/UPPER), je mise sur des colonnes g\u00e9n\u00e9r\u00e9es au lieu de fonctions dans WHERE. Pour les longs champs de texte, je n'indexe jamais \u00e0 l'aveugle - je mesure combien de pr\u00e9fixes suffisent pour atteindre une cardinalit\u00e9 \u00e9lev\u00e9e et je choisis le pr\u00e9fixe en cons\u00e9quence.<\/p>\n\n<h2>Anti-patterns qui neutralisent les indices<\/h2>\n<p>Certains mod\u00e8les font perdre beaucoup de temps et emp\u00eachent l'utilisation d'index :<\/p>\n<ul>\n  <li><strong>Fonctions sur les colonnes d'index<\/strong> dans le WHERE (par exemple DATE(post_date)) emp\u00eachent l'utilisation de l'index existant. Au lieu de cela, je filtre par plages (post_date &gt;= ... AND post_date &lt; ...).<\/li>\n  <li><strong>Cartes joker directrices<\/strong> dans LIKE (\u201ac\u2018) ne sont pas indexables. Je r\u00e9organise (recherche par pr\u00e9fixe, texte int\u00e9gral, autre structure de donn\u00e9es).<\/li>\n  <li><strong>Trop d'indices<\/strong> sur la m\u00eame colonne ou avec le m\u00eame pr\u00e9fixe de gauche n'apportent gu\u00e8re d'avantages, mais augmentent les co\u00fbts d'\u00e9criture. Je consolide les chevauchements.<\/li>\n  <li><strong>ORDER BY<\/strong> sur des colonnes qui n'apparaissent pas dans l'index conduit \u00e0 des filesorts. Si le tri est critique pour l'entreprise, je construis l'index composite appropri\u00e9.<\/li>\n<\/ul>\n\n<h2>Hygi\u00e8ne de l'index : r\u00e9duire les doublons et les conserver de mani\u00e8re cibl\u00e9e<\/h2>\n<p>Avec SHOW INDEX, je trouve des structures redondantes, par exemple un index unique sur post_status \u00e0 c\u00f4t\u00e9 d'un index compos\u00e9 (post_status, post_date). Souvent, je peux supprimer l'index unique, car l'index compos\u00e9 couvre le pr\u00e9fixe de gauche. En m\u00eame temps, je conserve des index qui semblent similaires mais qui servent d'autres chemins d'interrogation (par exemple (post_author) vs (post_status, post_date)). Je documente sciemment les raisons pour lesquelles un index reste ou dispara\u00eet, afin que les mises \u00e0 jour des th\u00e8mes\/plugins n'apportent pas de surprises par la suite.<\/p>\n\n<h2>Planification de la capacit\u00e9 : Buffer Pool, I\/O et Index-Footprint<\/h2>\n<p>Les index n'acc\u00e9l\u00e8rent que si les pages pertinentes sont dans le <strong>Pool de m\u00e9moire tampon<\/strong> se trouvent. Je veille \u00e0 ce que la taille des index fr\u00e9quemment utilis\u00e9s et des donn\u00e9es tienne dans la m\u00e9moire. Si le volume de donn\u00e9es augmente, je v\u00e9rifie d'abord quels index portent vraiment, je r\u00e9duis la longueur des pr\u00e9fixes et je supprime les combinaisons rarement utilis\u00e9es. Ce n'est que lorsque le volume de travail est propre qu'il vaut la peine d'augmenter la RAM. En cas de charge d'\u00e9criture \u00e9lev\u00e9e, je fais attention aux E\/S suppl\u00e9mentaires en soignant les index et j'\u00e9vite une indexation \u201etout risque\u201c exag\u00e9r\u00e9e.<\/p>\n\n<h2>Mesure et contr\u00f4le avanc\u00e9s<\/h2>\n<p>En plus d'EXPLAIN, je mise sur des mesures en production : le slow_query_log avec des valeurs seuils r\u00e9alistes me montre les valeurs aberrantes, et une analyse de mod\u00e8les des requ\u00eates les plus fr\u00e9quentes fait appara\u00eetre des tendances. Apr\u00e8s des modifications d'index, je v\u00e9rifie la cardinality dans SHOW INDEX, j'analyse le nombre de lignes concern\u00e9es (rows_examined) et j'observe le taux de cache et la latence. Je r\u00e9p\u00e8te ce cycle r\u00e9guli\u00e8rement, car les profils d'utilisation changent en raison de nouvelles fonctionnalit\u00e9s, de plugins ou de pics de trafic.<\/p>\n\n<h2>R\u00e9sum\u00e9<\/h2>\n<p>Je mets <strong>Index des bases de donn\u00e9es<\/strong> o\u00f9 les requ\u00eates s\u00e9lectives et r\u00e9currentes sont en cours, et les laisser de c\u00f4t\u00e9 l\u00e0 o\u00f9 l'\u00e9criture domine. Dans WordPress, wp_posts, wp_postmeta, wp_comments et wp_users fournissent les plus grands b\u00e9n\u00e9fices lorsque je couvre les filtres r\u00e9els. La mesure avec EXPLAIN, Query Monitor et slow_query_log me guide de mani\u00e8re fiable vers les bons candidats. L'entretien de wp_options, la mise en cache et une bonne conception des requ\u00eates emp\u00eachent les index de masquer les sympt\u00f4mes au lieu de r\u00e9soudre les causes. Ainsi, la base de donn\u00e9es reste rapide, la charge d'\u00e9criture reste dans les limites et les <strong>Performance<\/strong> stable - sans indexation aveugle.<\/p>","protected":false},"excerpt":{"rendered":"<p>WordPress database index expliqu\u00e9 : quand les index de base de donn\u00e9es boostent-ils les performances de WordPress et quand ne le font-ils pas ? Conseils de r\u00e9glage MySQL WP.<\/p>","protected":false},"author":1,"featured_media":16871,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-16878","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"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":"1268","_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":null,"_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-Indizes","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":"16871","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16878","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=16878"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16878\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/16871"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=16878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=16878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=16878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}