WooCommerce : commandes lentes dans l’administration — détecter les requêtes lourdes et les accélérer

Playbook de diagnostic rapide

Quand l’écran Commandes de l’admin est lent, vous voulez une boucle serrée : reproduire, mesurer, identifier la requête la plus lente,
puis décider si vous corrigez la forme des données, les index, le cache ou le comportement d’un plugin. Voici l’ordre des opérations
qui trouve rapidement le goulot d’étranglement.

Première étape : confirmer où passe le temps

• Waterfall du navigateur / TTFB : si le Time To First Byte est énorme, c’est côté serveur. Si le TTFB est correct mais le rendu traîne, c’est du JS front-end ou un payload HTML énorme.
• PHP-FPM slowlog : si les workers PHP sont bloqués dans des appels DB, vous le verrez. S’ils sont bloqués dans des appels HTTP, vous le verrez aussi.
• Base de données : cherchez des temps de requête longs, des locks, ou des lignes massives examinées.

Deuxième étape : capturer la pire requête, pas toutes les requêtes

• MySQL slow query log (temporaire, ciblé) pour attraper les endpoints admin.
• Performance Schema pour classer les statements par temps total.
• Query Monitor (si vous pouvez l’installer) pour voir la requête exacte et la pile d’appels.

Troisième étape : décider de la classe de correctif

• Index manquant/inefficace : ajouter un index composite, ou arrêter les scans meta non indexés.
• Explosion des jointures meta : réduire les filtres, réécrire avec de meilleures clés, ou passer à HPOS.
• Bloat de plugin : désactiver les fonctionnalités qui ajoutent des joins/colonnes à la liste des Commandes ; corriger les patterns N+1.
• Contention : locks dus aux imports/webhooks/cron ; planifier et batcher le travail.
• Absence/mauvaise utilisation du cache : ajouter un cache objet, mais ne tentez pas de cacher un scan complet de table.

L’objectif n’est pas « le rendre plus rapide » au sens abstrait. L’objectif est de transformer la page Commandes d’une ferme à requêtes
en un accès indexé et prévisible. Moins de lignes examinées, moins de jointures et moins de surprises.

Faits et contexte intéressants (pourquoi ça revient souvent)

Un peu de contexte vous évite de vous battre contre la guerre précédente. Les problèmes de performance admin WooCommerce ne sont ni nouveaux ni aléatoires.
Voici des faits concrets qui expliquent les motifs que vous verrez.

1. Le modèle original « tout est un post » de WordPress a fait rentrer produits et commandes dans wp_posts, mais il a aussi poussé des données structurées dans wp_postmeta, une table qui se dégrade mal à grande échelle.
2. Les tables meta sont de type EAV (entity-attribute-value). Excellentes pour la flexibilité, médiocres pour filtrer et trier, et vraiment mauvaises quand plusieurs clés meta sont combinées dans une requête.
3. WooCommerce stockait historiquement les données de commande dans posts/postmeta, donc filtrer les commandes par statut, date, total, moyen de paiement ou champs client implique souvent des jointures contre wp_postmeta.
4. Les index secondaires InnoDB n’entreposent pas toute la ligne. Ils stockent les colonnes indexées plus la clé primaire. Si votre requête a besoin d’autres champs, cela peut signifier plus de lectures de pages.
5. « Lignes examinées » est souvent le vrai coupable. Une requête de 200 ms qui examine 20 millions de lignes est une panne de production en attente de montée de trafic.
6. HPOS (High-Performance Order Storage) existe surtout parce que wp_posts/wp_postmeta ne tenait pas la charge pour les boutiques à fort volume de commandes sans patrons de requête pénibles.
7. MySQL ne peut pas utiliser efficacement deux index séparés pour certains patterns multi-condition comme les gens l’espèrent. Les index composites battent souvent l’optimisme « j’ai ajouté un index par colonne ».
8. Les pages d’admin sont privilégiées et lourdes—elles calculent des agrégats, chargent des objets liés et exécutent des vérifications de capacités. Vous mesurez un bus, pas une bicyclette.
9. COUNT(*) peut être coûteux en InnoDB car il ne conserve pas un compteur de lignes bon marché comme certains moteurs. Les listes de commandes qui calculent les totaux par statut peuvent coûter cher.

Si vous retenez une chose de l’historique : la lenteur de l’admin WooCommerce est généralement un problème de disposition des données déguisé en PHP.

À quoi ressemble une « page Commandes lente » en production

« Commandes lente » peut recouvrir au moins cinq modes de défaillance différents. Traitez-les différemment.

Mode de défaillance A : long TTFB, puis la page charge

Le serveur travaille avant d’envoyer le HTML. Généralement des requêtes MySQL, parfois des appels distants (tarifs d’expédition, statut de paiement),
et occasionnellement des graphes d’objets PHP massifs.

Mode de défaillance B : la page charge, mais le tableau Commandes reste vide un moment

Souvent des composants pilotés par AJAX, des endpoints REST, ou des récupérations de la table de liste en arrière-plan.
Vérifiez admin-ajax et les temps de réponse REST, pas seulement la requête principale.

Mode de défaillance C : timeouts intermittents

Contention classique. Un job cron, un import, une tempête de webhooks, ou une sauvegarde chevauche l’usage admin.
Ou vous saturez les workers PHP-FPM et les requêtes admin font la queue jusqu’à expiration.

Mode de défaillance D : seuls certains utilisateurs le voient

Les rôles comptent. Certains plugins ajoutent des colonnes/actions seulement pour les administrateurs, ou chargent des intégrations supplémentaires
selon les capacités de l’utilisateur. De plus, les options d’affichage utilisateur peuvent changer la taille de la liste.

Mode de défaillance E : c’est rapide en staging, lent en prod

Staging a 2 000 commandes. La production a 2 000 000 de lignes de postmeta. Félicitations, vous avez découvert l’échelle.

Blague #1 : si votre page Commandes ne ralentit que pendant les grosses ventes, ce n’est pas « mystérieux »—c’est votre base de données qui demande une pause syndicale.

Instrumentation qui dit la vérité (pas des impressions)

Vous ne pouvez pas optimiser ce que vous ne pouvez pas observer. Mais vous ne pouvez pas non plus tout observer sans causer de nouveaux problèmes.
L’astuce est d’ajouter une visibilité ciblée pour les endpoints admin et de la retirer une fois que vous avez les preuves.

Choisissez votre outil selon les contraintes

• Sûr en production, faible overhead : MySQL slow query log (avec seuils raisonnables), résumés digest du Performance Schema, PHP-FPM slowlog.
• Plus de détails, plus de risques : plugin Query Monitor en production (parfois ok, souvent non), general query log complet (presque jamais).
• Le meilleur des deux si vous l’avez : tracing APM (New Relic, Datadog, etc.). Mais vous devez toujours comprendre le SQL.

Une citation pour vous garder honnête

L’espoir n’est pas une stratégie. — General Gordon R. Sullivan

Dans ce contexte : ne « priez » pas pour que Redis règle une requête qui scanne toute la table meta.
Mesurez d’abord. Puis corrigez la chose spécifique qui est lente.

Tâches pratiques : commandes, sorties, décisions

Ce sont des tâches réelles que vous pouvez exécuter sur une pile typique Linux + Nginx/Apache + PHP-FPM + MySQL/MariaDB.
Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie, et la décision à prendre.
Exécutez-les dans cet ordre si vous êtes en intervention.

Tâche 1 : Confirmer l’endpoint lent et les temps depuis les logs d’accès

cr0x@server:~$ sudo awk '$7 ~ /wp-admin\/edit.php/ && $0 ~ /post_type=shop_order/ {print $4,$7,$9,$10,$NF}' /var/log/nginx/access.log | tail -n 5
[27/Dec/2025:11:04:11 /wp-admin/edit.php?post_type=shop_order 200 81234 6.982
[27/Dec/2025:11:04:29 /wp-admin/edit.php?post_type=shop_order 200 80991 7.104
[27/Dec/2025:11:05:02 /wp-admin/edit.php?post_type=shop_order 504 0 30.001
[27/Dec/2025:11:05:45 /wp-admin/edit.php?post_type=shop_order 200 81012 8.331
[27/Dec/2025:11:06:13 /wp-admin/edit.php?post_type=shop_order 200 81120 7.955

Ce que cela signifie : les requêtes de la liste Commandes prennent 7–8 secondes, avec des 504 occasionnels à 30 secondes (timeout proxy).

Décision : Traitez cela comme une latence côté serveur. Passez à l’inspection PHP-FPM et DB, pas aux ajustements front-end.

Tâche 2 : Vérifier la saturation PHP-FPM (la mise en file ressemble à une « lenteur aléatoire »)

cr0x@server:~$ sudo ss -s
Total: 2181
TCP:   1612 (estab 204, closed 1298, orphaned 0, timewait 120)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       9         7         2
TCP       314       247       67
INET      323       254       69
FRAG      0         0         0

Ce que cela signifie : Pas définitif, mais une pile de connexions peut laisser présager un backlog. Il vous faut le statut PHP-FPM.

Décision : Si vous n’avez pas le statut PHP-FPM activé, activez-le (temporairement, restreint). Ensuite inspectez workers actifs/idle.

Tâche 3 : Lire le statut du pool PHP-FPM (actifs vs max children)

cr0x@server:~$ curl -s http://127.0.0.1/status?full | egrep -i 'active processes|max active processes|idle processes|max children reached|slow requests'
active processes: 24
max active processes: 24
idle processes: 0
max children reached: 93
slow requests: 117

Ce que cela signifie : Vous êtes au max children avec zéro worker idle ; les requêtes font la queue. Le système est surchargé ou bloqué.

Décision : Ne vous contentez pas d’augmenter pm.max_children. Trouvez ce qui bloque les workers (souvent des appels DB). Passez au slowlog et à la DB.

Tâche 4 : Activer PHP-FPM slowlog pour une courte fenêtre

cr0x@server:~$ sudo grep -nE 'slowlog|request_slowlog_timeout' /etc/php/8.2/fpm/pool.d/www.conf
255:;slowlog = /var/log/php8.2-fpm/slow.log
256:;request_slowlog_timeout = 5s

cr0x@server:~$ sudo sed -i 's#^;slowlog =.*#slowlog = /var/log/php8.2-fpm/slow.log#; s#^;request_slowlog_timeout =.*#request_slowlog_timeout = 5s#' /etc/php/8.2/fpm/pool.d/www.conf
cr0x@server:~$ sudo systemctl reload php8.2-fpm

Ce que cela signifie : les requêtes de plus de 5 secondes vont produire une trace de pile.

Décision : Reproduisez le chargement lent des Commandes une ou deux fois, inspectez le slow log et désactivez-le si c’est trop verbeux.

Tâche 5 : Inspecter le PHP-FPM slowlog pour voir où passe le temps

cr0x@server:~$ sudo tail -n 30 /var/log/php8.2-fpm/slow.log
[27-Dec-2025 11:07:44]  [pool www] pid 22144
script_filename = /var/www/html/wp-admin/edit.php
[0x00007f1c2b9d0a80] mysqli_query() /var/www/html/wp-includes/wp-db.php:2351
[0x00007f1c2b9d0a10] _do_query() /var/www/html/wp-includes/wp-db.php:2265
[0x00007f1c2b9d08b0] query() /var/www/html/wp-includes/wp-db.php:3132
[0x00007f1c2b9d06e0] get_results() /var/www/html/wp-includes/wp-db.php:3645
[0x00007f1c2b9d05d0] query() /var/www/html/wp-content/plugins/woocommerce/includes/data-stores/class-wc-order-data-store-cpt.php:...

Ce que cela signifie : Les workers sont bloqués en MySQL. Il vous faut maintenant le SQL exact et son plan.

Décision : Activez le slow query log MySQL ou utilisez Performance Schema pour capturer l’instruction précise.

Tâche 6 : Activer le slow query log MySQL en toute sécurité (temporaire, seuil)

cr0x@server:~$ mysql -uroot -p -e "SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'long_query_time'; SHOW VARIABLES LIKE 'slow_query_log_file';"
Enter password:
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| slow_query_log | OFF   |
+----------------+-------+
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| long_query_time | 10.000|
+-----------------+-------+
+---------------------+-------------------------------+
| Variable_name       | Value                         |
+---------------------+-------------------------------+
| slow_query_log_file | /var/log/mysql/mysql-slow.log |
+---------------------+-------------------------------+

cr0x@server:~$ mysql -uroot -p -e "SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL log_queries_not_using_indexes = 'ON';"
Enter password:

Ce que cela signifie : Les requêtes lentes de plus d’une seconde (et celles n’utilisant pas d’index) seront journalisées. Suffisant pour attraper la lenteur admin sans se noyer.

Décision : Reproduisez la page Commandes. Analysez immédiatement le slow log et désactivez les réglages si le volume est trop élevé.

Tâche 7 : Trouver les pires requêtes admin WooCommerce dans le slow log

cr0x@server:~$ sudo pt-query-digest /var/log/mysql/mysql-slow.log | sed -n '1,120p'
#  1.2s user time, 40ms system time, 27.43M rss, 1.18G vsz
# Current date: Fri Dec 27 11:10:01 2025
# Overall: 193 total, 19 unique, 0.03 QPS, 0.21x concurrency _____________
# Time range: 2025-12-27T11:06:11 to 2025-12-27T11:09:55
# Attribute          total     min     max     avg     95%  stddev  median
# ============     ======= ======= ======= ======= ======= ======= =======
# Query time        301.2s   0.002s  28.991s   1.561s   6.821s   3.102s   0.912s
# Rows examined     1.62G       10  38.12M   8.39M  22.01M   9.11M   6.33M
# Profile
# Rank Query ID                      Response time Calls R/Call  V/M   Item
# ==== ============================= ============= ===== ======= ===== ============
#    1 0x7A2F1F8E3C2B4A1D            172.2330  41  4.2008  0.80  SELECT wp_posts ...
#    2 0x9B1A0E21FF77C0B4             68.1192  22  3.0963  0.62  SELECT wp_postmeta ...

Ce que cela signifie : Des lignes massives examinées. Ce n’est pas un problème « PHP lent ». C’est un accès aux données.

Décision : Extraire l’empreinte de requête la plus lourde et exécuter EXPLAIN / EXPLAIN ANALYZE. Vous recherchez des scans complets, un mauvais ordre de jointure, et l’utilisation de temp tables/filesort.

Tâche 8 : Récupérer l’échantillon de requête exact et lancer EXPLAIN

cr0x@server:~$ sudo grep -n "SELECT .*wp_posts" -m 1 -A 20 /var/log/mysql/mysql-slow.log | sed -n '1,25p'
# Time: 2025-12-27T11:08:12.123456Z
# Query_time: 6.821  Lock_time: 0.002 Rows_sent: 25  Rows_examined: 22010431
SET timestamp=1766833692;
SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID
FROM wp_posts
LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
WHERE 1=1
AND ( wp_postmeta.meta_key = '_billing_email' AND wp_postmeta.meta_value LIKE '%@example.com%' )
AND wp_posts.post_type = 'shop_order'
ORDER BY wp_posts.post_date DESC
LIMIT 0, 25;

cr0x@server:~$ mysql -uroot -p wordpress -e "EXPLAIN SELECT wp_posts.ID FROM wp_posts LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id ) WHERE ( wp_postmeta.meta_key = '_billing_email' AND wp_postmeta.meta_value LIKE '%@example.com%' ) AND wp_posts.post_type = 'shop_order' ORDER BY wp_posts.post_date DESC LIMIT 0,25\G"
Enter password:
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: wp_postmeta
   partitions: NULL
         type: ref
possible_keys: post_id,meta_key
          key: meta_key
      key_len: 191
          ref: const
         rows: 4821031
     filtered: 10.00
        Extra: Using where; Using temporary; Using filesort
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: wp_posts
         type: eq_ref
possible_keys: PRIMARY,type_status_date
          key: PRIMARY
      key_len: 8
          ref: wordpress.wp_postmeta.post_id
         rows: 1
        Extra: Using where

Ce que cela signifie : MySQL part de wp_postmeta en utilisant meta_key, puis balaie des millions de lignes pour appliquer le filtre LIKE.
« Using temporary; Using filesort » indique un travail supplémentaire pour le tri.

Décision : Arrêtez les recherches wildcard sur meta_value à grande échelle, ou adoptez une stratégie : recherches exactes, tables de lookup normalisées, ou HPOS. Si vous devez supporter la recherche d’emails, utilisez des patterns ancrés au début ou une colonne/table indexée dédiée.

Tâche 9 : Vérifier les index existants sur wp_postmeta (et s’ils aident)

cr0x@server:~$ mysql -uroot -p wordpress -e "SHOW INDEX FROM wp_postmeta;"
Enter password:
+------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table      | Non_unique | Key_name  | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| wp_postmeta|          0 | PRIMARY   |            1 | meta_id     | A         |     98122312|     NULL | NULL   |      | BTREE      |         |               | YES     | NULL       |
| wp_postmeta|          1 | post_id   |            1 | post_id     | A         |     33511291|     NULL | NULL   |      | BTREE      |         |               | YES     | NULL       |
| wp_postmeta|          1 | meta_key  |            1 | meta_key    | A         |        2412 |      191 | NULL   | YES  | BTREE      |         |               | YES     | NULL       |
+------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+

Ce que cela signifie : Les index par défaut existent, mais il n’y a pas d’index composite comme (meta_key, meta_value) ou (meta_key, post_id) qui aide certains patterns.

Décision : N’ajoutez pas aveuglément (meta_key, meta_value) car meta_value est du longtext et l’indexer demande un préfixe et de la prudence. Préférez corriger le pattern de requête (éviter le LIKE wildcard) ou migrer vers HPOS. Si vous ajoutez des index, ajoutez l’index composite le plus petit et sélectif correspondant à votre WHERE et join.

Tâche 10 : Vérifier le volume de commandes et le gonflement du postmeta (l’échelle compte)

cr0x@server:~$ mysql -uroot -p wordpress -e "SELECT COUNT(*) AS orders FROM wp_posts WHERE post_type='shop_order'; SELECT COUNT(*) AS order_meta_rows FROM wp_postmeta pm JOIN wp_posts p ON p.ID=pm.post_id WHERE p.post_type='shop_order';"
Enter password:
+--------+
| orders |
+--------+
| 218942 |
+--------+
+-----------------+
| order_meta_rows |
+-----------------+
| 18320177        |
+-----------------+

Ce que cela signifie : ~219k commandes mais ~18M de lignes meta pour les commandes. Ce n’est pas inhabituel, mais ça explique pourquoi les filtres basés sur meta sont pénalisants.

Décision : Si vous êtes encore sur le stockage legacy des commandes, envisagez fortement HPOS pour la performance. Si vous ne pouvez pas, contraignez le comportement de recherche admin et corrigez les quelques patterns de requête principaux.

Tâche 11 : Voir les digests SQL principaux par temps total (Performance Schema)

cr0x@server:~$ mysql -uroot -p -e "SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 AS total_sec, AVG_TIMER_WAIT/1000000000000 AS avg_sec, SUM_ROWS_EXAMINED FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 3\G"
Enter password:
*************************** 1. row ***************************
DIGEST_TEXT: SELECT SQL_CALC_FOUND_ROWS `wp_posts`.`ID` FROM `wp_posts` LEFT JOIN `wp_postmeta` ON ( `wp_posts`.`ID` = `wp_postmeta`.`post_id` ) WHERE ...
 COUNT_STAR: 97
 total_sec: 214.731
   avg_sec: 2.214
SUM_ROWS_EXAMINED: 913200112
*************************** 2. row ***************************
DIGEST_TEXT: SELECT `meta_id`, `post_id`, `meta_key`, `meta_value` FROM `wp_postmeta` WHERE `post_id` IN ( ... )
 COUNT_STAR: 412
 total_sec: 71.334
   avg_sec: 0.173
SUM_ROWS_EXAMINED: 18445022

Ce que cela signifie : L’instruction la plus lourde est le pattern de la liste Commandes. La seconde est un pattern de récupération meta qui peut être une variante N+1.

Décision : Optimisez d’abord le digest #1. Si vous corrigez le pattern n°1, vous réglez généralement la perception « l’admin est lent ».

Tâche 12 : Vérifier la contention autour des tables de commandes

cr0x@server:~$ mysql -uroot -p -e "SHOW ENGINE INNODB STATUS\G" | egrep -n 'LATEST DETECTED DEADLOCK|TRANSACTIONS|LOCK WAIT|wait' | head -n 40
Enter password:
72:TRANSACTIONS
85:---TRANSACTION 93488322, ACTIVE 18 sec starting index read
86:mysql tables in use 1, locked 1
87:LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
88:MySQL thread id 221, OS thread handle 140067524396800, query id 9123219 10.0.2.14 wordpress updating

Ce que cela signifie : Des transactions attendent des locks. Cela peut transformer une « lenteur parfois » en « inutilisable aléatoirement ».

Décision : Identifiez la requête qui verrouille (PROCESSLIST), puis décidez : réduire la portée des transactions, batcher les mises à jour, déplacer les imports hors-pointe, ou ajuster isolation/locks si approprié.

Tâche 13 : Identifier la requête bloquante en direct

cr0x@server:~$ mysql -uroot -p -e "SHOW FULL PROCESSLIST;" | head -n 15
Enter password:
+-----+---------+-----------+-----------+---------+------+------------------------+------------------------------+
| Id  | User    | Host      | db        | Command | Time | State                  | Info                         |
+-----+---------+-----------+-----------+---------+------+------------------------+------------------------------+
| 221 | wp_user | 10.0.2.14 | wordpress | Query   |   18 | updating               | UPDATE wp_postmeta SET ...   |
| 227 | wp_user | 10.0.2.19 | wordpress | Query   |    7 | Sending data           | SELECT SQL_CALC_FOUND_ROWS...|
| 229 | wp_user | 10.0.2.19 | wordpress | Query   |    6 | Waiting for table lock | SELECT ... wp_postmeta ...   |
+-----+---------+-----------+-----------+---------+------+------------------------+------------------------------+

Ce que cela signifie : Un UPDATE tourne longtemps et cause des attentes. Le SELECT de Commandes subit des dommages collatéraux.

Décision : Si l’UPDATE provient d’un plugin effectuant des modifications massives de meta, limitez-le, batcher-le, ou déplacez-le dans une file. Ne laissez pas des jobs « en arrière-plan » partager l’heure de pointe avec les workflows admin.

Tâche 14 : Vérifier le buffer pool InnoDB et si vous êtes lié au disque

cr0x@server:~$ mysql -uroot -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads'; SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';"
Enter password:
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 2147483648 |
+-------------------------+------------+
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| Innodb_buffer_pool_reads | 918221 |
+--------------------------+--------+
+--------------------------------+-----------+
| Variable_name                  | Value     |
+--------------------------------+-----------+
| Innodb_buffer_pool_read_requests | 918221223 |
+--------------------------------+-----------+

Ce que cela signifie : 2 Go de buffer pool est petit pour une boutique WooCommerce occupée avec des millions de lignes meta. Les lectures disque sont non négligeables.

Décision : Si l’hôte DB a de la RAM disponible, augmentez le buffer pool (prudemment). Mais faites-le après avoir corrigé les pires requêtes ; sinon vous ne faites que cacher un mauvais comportement.

Tâche 15 : Vérifier la présence et le taux de hit du cache objet (ex. Redis)

cr0x@server:~$ redis-cli INFO stats | egrep 'keyspace_hits|keyspace_misses'
keyspace_hits:18382122
keyspace_misses:8821331

Ce que cela signifie : Le taux de hit est d’environ 67 %. Pas terrible, pas mauvais. Les pages admin peuvent quand même manquer beaucoup si les clés ne sont pas persistantes ou si les TTL sont courts.

Décision : Assurez-vous qu’un drop-in de cache objet persistant est actif et pas désactivé pour l’admin. Mais ne poursuivez pas un taux de 99 % comme une religion ; corrigez d’abord le SQL le plus lent.

Tâche 16 : Profiler les hooks WordPress et les appels lents avec WP-CLI (suspects plugins)

cr0x@server:~$ wp --path=/var/www/html --allow-root plugin list --status=active
+-------------------------------+--------+-----------+---------+
| name                          | status | update    | version |
+-------------------------------+--------+-----------+---------+
| woocommerce                   | active | available | 8.8.3   |
| woocommerce-subscriptions     | active | none      | 6.6.0   |
| some-order-exporter           | active | none      | 2.1.4   |
| query-monitor                 | inactive | none    | 3.15.0  |
+-------------------------------+--------+-----------+---------+

Ce que cela signifie : Vous avez quelques modificateurs probables de la liste Commandes (exporters, subscriptions, CRM) qui ajoutent souvent des joins/colonnes.

Décision : Testez la désactivation des suspects en staging, ou en production pendant une fenêtre contrôlée, et mesurez de nouveau le temps de chargement des Commandes et les slow queries.

Tâche 17 : Mesurer le temps de réponse côté serveur (curl comme réalité)

cr0x@server:~$ curl -s -o /dev/null -w "ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n" -H "Cookie: wordpress_logged_in_x=REDACTED" "https://shop.example.com/wp-admin/edit.php?post_type=shop_order"
ttfb=6.742 total=7.118 code=200

Ce que cela signifie : Le TTFB représente la majeure partie du total, confirmant un goulot côté serveur.

Décision : Continuez à vous concentrer sur DB/PHP, pas sur la minification des assets admin.

Tâche 18 : Surveiller la latence disque (parce que les bases de données détestent le stockage lent)

cr0x@server:~$ iostat -x 1 5
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.02    0.00    3.11    8.44    0.00   79.43

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         210.0    95.0  8420.0  6120.0     68.0     4.20   14.80    18.90     5.10   0.55  16.8

Ce que cela signifie : 8 % d’iowait et ~19 ms de read await peuvent amplifier les mauvais plans de requête. Pas catastrophique, mais pas gratuit.

Décision : Si vous corrigez les requêtes et voyez encore un await élevé sous charge admin, envisagez une amélioration du stockage ou d’isoler l’I/O DB des voisins bruyants.

Tâche 19 : Annuler l’instrumentation temporaire (soyez un bon citoyen)

cr0x@server:~$ mysql -uroot -p -e "SET GLOBAL slow_query_log='OFF'; SET GLOBAL long_query_time=10; SET GLOBAL log_queries_not_using_indexes='OFF';"
Enter password:

Ce que cela signifie : Vous avez capturé des preuves et réduit l’overhead en cours.

Décision : Gardez une trace écrite des digests et plans principaux. Optimiser sans notes est la façon dont les équipes régressent six mois plus tard.

Patrons courants de requêtes lourdes dans l’admin WooCommerce

Une fois que vous avez des échantillons de requêtes lentes et des sorties EXPLAIN, vous commencerez à voir des répétitions. La lenteur admin WooCommerce est souvent juste
trois ou quatre motifs avec des paramètres différents.

Pattern 1 : filtrage meta avec LIKE sur meta_value

La recherche de commandes par email, nom, adresse, ou tout ce qui est stocké en postmeta tend à faire :
filtrer par meta_key puis scanner de nombreuses lignes pour appliquer LIKE '%...%'. Le wildcard en tête détruit l’utilité de l’index.

Indice de diagnostic : EXPLAIN commence par wp_postmeta, « rows » élevé, « Using temporary; Using filesort ».

Direction de correction : Changez le comportement de recherche (exact/prefix), utilisez HPOS, ou créez des tables de lookup indexées dédiées. Les index-prefix sur du longtext sont un pansement risqué.

Pattern 2 : ORDER BY post_date avec WHERE large, provoquant filesort

La liste Commandes utilise un tri (date, total, statut) et la pagination. Si MySQL ne peut pas satisfaire ORDER BY depuis un index,
il trie beaucoup de candidats puis renvoie 25 lignes.

Indice de diagnostic : « Using filesort » et énormes lignes examinées.

Direction de correction : Améliorer la sélectivité, ajouter des index composites qui correspondent à WHERE + ORDER BY, ou changer le modèle de stockage (HPOS) quand le schéma le permet.

Pattern 3 : SQL_CALC_FOUND_ROWS / requêtes de comptage pour la pagination

Les tableaux de liste aiment calculer le nombre total de résultats. Sur de grands jeux de données, compter peut coûter plus cher que récupérer les 25 lignes affichées.

Indice de diagnostic : Requête similaire apparaît deux fois : une pour les IDs, une pour FOUND_ROWS ou COUNT.

Direction de correction : Réduire les filtres coûteux ; dans certains environnements, ajuster l’UX admin (ne pas calculer des totaux exacts pour chaque filtre).

Pattern 4 : récupérations N+1 de meta pour chaque ligne de commande

L’écran Commandes affiche des colonnes : nom de facturation, total, statut, moyen de paiement, méthode d’envoi, notes, et colonnes personnalisées ajoutées par des plugins.
Chaque colonne peut déclencher des lookups additionnels si les données ne sont pas préchargées.

Indice de diagnostic : Beaucoup de SELECT ... FROM wp_postmeta WHERE post_id IN (...) similaires ou même des requêtes par commande.

Direction de correction : Réduire les colonnes personnalisées, assurer que le cache du data store WooCommerce est efficace, utiliser le cache objet, ou migrer vers une version qui précharge plus efficacement.

Pattern 5 : joins et sous-requêtes ajoutés par des plugins

Les CRM, exporters, outils antifraude et plugins « gestion des commandes » aiment hooker les requêtes de la liste admin et ajouter des WHERE supplémentaires.
Chacun semble petit. Ensemble, ils créent un plan de requête qui ressemble à un bol de spaghetti renversé.

Indice de diagnostic : Requête lente incluant des meta keys inattendues, des joins taxonomie, ou des tables personnalisées.

Direction de correction : Désactivez et mesurez. Si l’entreprise a besoin du plugin, demandez au fournisseur des conseils pour tuner la requête ou isolez les fonctionnalités à des écrans spécifiques.

Blague #2 : SQL est comme un chat — si vous l’ignorez, il viendra quand même s’asseoir sur votre clavier et empirera tout.

Accélérations efficaces (et ce qu’elles cassent)

Soyons francs : la plupart des « guides de perf » recommandent du cache et de la prière. Nous faisons moins de lignes examinées, de meilleurs index,
et moins de fonctionnalités inutiles. Voici des correctifs qui font réellement bouger l’aiguille.

1) Activer HPOS (High-Performance Order Storage) quand c’est faisable

HPOS déplace les données de commande hors des posts/postmeta vers des tables dédiées conçues pour les commandes. Le gain n’est pas subtil :
moins de jointures, meilleurs index, et des formes de requête plus prévisibles.

Ce que ça casse : Certains plugins supposent encore que les commandes vivent dans posts/postmeta. Vous devez tester la compatibilité,
surtout avec le fulfilment, les subscriptions et les outils de reporting. La migration elle-même nécessite de la planification.

Conseil tranché : Si vous avez des comptes de commandes à six chiffres et êtes toujours sur le stockage legacy, HPOS vaut généralement l’effort.
Plus vous attendez, plus la fenêtre de migration devient pénible.

2) Réduire le périmètre de recherche admin (arrêter les recherches « contient partout »)

Le pire pattern est la recherche saisie par l’utilisateur mappée sur meta_value en wildcard LIKE.
« Rechercher un email contenant ‘gmail’ » sonne utile. À l’échelle, c’est une feature de déni de service.

Options de correction :

• Exiger la correspondance exacte pour la recherche d’email de facturation.
• Utiliser la recherche par préfixe (LIKE 'abc%') plutôt que contains (LIKE '%abc%') quand possible.
• Ajouter une UI de recherche dédiée qui interroge une table indexée séparée (ou utilise une recherche externe) au lieu de scanner raw meta_value.

3) Ajouter des index composites ciblés (avec prudence)

Indexer les tables meta de WordPress est délicat : vous pouvez améliorer les lectures mais ralentir les écritures et gonfler le stockage.
Cela dit, certains index paient immédiatement.

Formes d’index utiles courantes :

• (post_id, meta_key) pour récupérer des clés spécifiques par commande efficacement (si votre workload le nécessite).
• (meta_key, post_id) pour les requêtes qui filtrent par meta_key puis joignent aux posts par post_id.

À éviter : Indexer aléatoirement meta_value à moins de comprendre parfaitement vos patterns et la distribution des données.
Les index préfixes peuvent aider pour les correspondances exactes/préfixes mais ne sauveront pas un LIKE commençant par wildcard.

4) Supprimer les colonnes et filtres admin chers ajoutés par des plugins

Chaque colonne personnalisée qui montre « une info de plus utile » peut déclencher des fetchs meta ou des joins supplémentaires.
Multipliez par 25 lignes par page et par chaque admin qui a l’écran ouvert.

Correction : Supprimez ou différer les colonnes. Si un plugin insiste, configurez-le pour ne pas modifier la requête de la liste Commandes,
ou déplacez ses données vers un écran séparé chargé à la demande.

5) Utiliser un cache objet persistant, mais considérez-le comme un multiplicateur

Redis/Memcached peuvent réduire les lookups répétés entre requêtes : options, usermeta, term cache, et caches d’objets WooCommerce.
Ça aide les pages admin car les administrateurs répètent des actions. Mais ça ne résout pas une requête unique qui effectue un scan énorme.

Correction : Assurez-vous que le cache objet est persistant et correctement dimensionné. Veillez aussi à ce qu’il ne soit pas vidé constamment par des scripts de déploiement ou des plugins de bust.

6) Apprivoiser les jobs en arrière-plan (Action Scheduler, imports, webhooks)

WooCommerce utilise Action Scheduler pour les tâches en arrière-plan. Si vous avez un backlog, il peut marteler la DB et priver les requêtes admin.
Les imports et plugins de sync peuvent faire pareil.

Correction : Limiter le débit, batcher, programmer hors-pointe. Ne lancez pas des mises à jour massives à midi puis soyez surpris que la page Commandes soit lente.

7) Dimensionner correctement la mémoire MySQL et réduire la douleur disque

Si votre buffer pool est minuscule, chaque requête admin devient une chasse sur disque. Augmentez le buffer pool si la RAM le permet,
surveillez l’absence de swap, et évitez de colocaliser la DB avec des workloads bruyants.

Correction : Augmentez progressivement innodb_buffer_pool_size, redémarrez dans une fenêtre de maintenance si nécessaire, puis mesurez à nouveau.
Si la latence du stockage est élevée, corrigez-la aussi—les bases de données ne sont pas patientes.

8) Mettre à jour WooCommerce et WordPress de façon stratégique

Des améliorations de performance arrivent souvent dans des releases mineures: moins de requêtes, meilleur cache, comportement de liste amélioré.
Rester trop en retard signifie que vous subissez des bugs déjà corrigés—juste pas sur vos serveurs.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Un retailer de taille intermédiaire utilisait WooCommerce depuis des années sans souci. Les commandes montaient en saison, mais le site restait en ligne.
Puis le support a commencé à se plaindre : cliquer sur « Commandes » expirait. L’équipe technique a regardé le CPU et a vu qu’il n’était pas saturé.
Ils ont conclu que c’était « le réseau » et sont passés à autre chose.

La mauvaise hypothèse : si le CPU est correct, la base de données doit l’être aussi. Pendant ce temps la DB examinait 20+ millions de lignes sur une requête de recherche
générée par un macro support : « rechercher les commandes par email client contenant ‘@gmail.com’ ». Ça fonctionnait à 30k commandes.
Avec 300k commandes, c’est devenu une machine à scans de table.

Ils l’ont « réglé » en augmentant les timeouts du proxy. La page Commandes a cessé de timeout… et a commencé à prendre 40 secondes.
Le support a arrêté d’utiliser l’écran et a demandé à l’ingénierie d’exécuter des requêtes manuelles pour eux.
Ce n’est pas un contournement ; c’est une panne lente.

La vraie correction était peu glamour : supprimer la recherche contenant sur l’email de facturation dans l’UI admin, la remplacer par une correspondance exacte et un lookup client séparé qui retournait les emails connus du client. Le support s’est plaint pendant une semaine, puis a oublié.
La page Commandes est tombée sous deux secondes parce que la DB a cessé d’être sollicitée pour un travail impossible.

Leçon : les échecs de performance sont souvent des décisions produit. Si votre UI encourage des requêtes pathologiques, votre base de données finira par imposer la physique.

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre entreprise avait un ingénieur amateur d’index. La page Commandes était lente, alors il a ajouté plein d’index sur wp_postmeta,
y compris un index préfixe sur meta_value pour plusieurs clés. Ils ont aussi ajouté quelques composites « au cas où ».
En benchmark rapide, tout semblait super.

Deux semaines plus tard, la création de commande ralentissait. Puis les remboursements ralentissaient. Puis les jobs en arrière-plan ont commencé à s’accumuler.
Les écritures payaient le prix de l’entretien d’une forêt d’index secondaires. La boutique n’était pas en panne, mais tout était collant,
comme marcher dans un couloir moquetté avec des chaussures mouillées.

Pire : les nouveaux index ont changé les choix du planificateur. Certaines requêtes se sont accélérées, d’autres sont devenues dramatiquement plus lentes parce que le planner a commencé
à utiliser un index qui semblait sélectif mais ne l’était pas. Soudain une requête auparavant acceptable est devenue longue, provoquant des contentions de locks.

Le rollback a été douloureux car supprimer des index sur de grandes tables n’est pas instantané. Ils ont fini par planifier des fenêtres de maintenance et les retirer un par un,
tout en corrigeant le vrai problème : un plugin qui générait des requêtes meta peu sélectives et avec des wildcards.

Leçon : les index ne sont pas gratuits. Ajoutez-les comme si vous les payiez de votre propre budget—parce que vous le faites, via la latence.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une boutique axée abonnement subissait une lenteur admin régulière chaque lundi matin. Ce n’était pas catastrophique, mais cela rendait l’équipe ops misérable.
L’ingénieur on-call a fini par faire la chose ennuyeuse : collecter les slow query logs pendant exactement 15 minutes chaque lundi pendant un mois,
puis comparer les digests et plans.

Le pattern était clair : Action Scheduler traitait un backlog de renouvellements d’abonnement, générant des pics d’écritures sur les meta et notes de commande,
qui chevauchaient le travail du personnel (remboursements, support). La DB allait bien hors-pointe ; c’était la contention sous charge mixte lecture/écriture.

Le correctif n’était pas héroïque. Ils ont limité le rythme du scheduler, déplacé le traitement des renouvellements à des heures plus tôt, et ajouté de l’observabilité :
si la profondeur de la queue dépassait un seuil, le scheduler ralentissait. Ils ont aussi créé un pool PHP-FPM dédié plus petit pour l’admin afin que le trafic client ne puisse pas priver le staff.

Le lundi matin est redevenu ennuyeux. L’entreprise a célébré en ne le remarquant pas, ce qui est le plus grand compliment que le métier des opérations puisse recevoir.

Leçon : la mesure répétée bat la panique ponctuelle. La pratique ennuyeuse consiste à collecter des preuves comparables dans le temps et à agir sur les motifs.

Erreurs fréquentes : symptôme → cause racine → correctif

Voici ce qui fait perdre des semaines. Reconnaître le symptôme, le mapper à une cause probable, et appliquer le correctif spécifique.

1) Symptom : la page Commandes est lente seulement avec la recherche admin

Cause racine : recherche meta utilisant LIKE '%term%' sur wp_postmeta.meta_value.

Fix : Restreindre la recherche à une correspondance exacte ou préfixe ; ajouter un lookup client dédié ; envisager HPOS. Éviter les recherches « contains » sur du longtext meta.

2) Symptom : timeouts de la page Commandes pendant des imports/sync

Cause racine : mises à jour massives tenant des locks et saturant l’I/O ; transactions longues ; jobs arrière-plan non throttlés.

Fix : Batcher les mises à jour, réduire la taille des transactions, programmer hors-pointe, limiter les runners d’Action Scheduler, et surveiller les lock waits.

3) Symptom : la page Commandes lente seulement pour les administrateurs

Cause racine : un plugin ajoute des colonnes/actions pour les admins, générant des requêtes ou joins supplémentaires.

Fix : Désactiver la fonctionnalité plugin pour la liste, supprimer les colonnes, ou déplacer les données vers une vue à la demande.

4) Symptom : CPU faible, mais latence élevée

Cause racine : lectures DB liées au disque à cause d’un buffer pool petit ou de mauvais plans.

Fix : Corriger les plans de requête d’abord ; ensuite augmenter le buffer pool ; valider la latence du stockage ; garantir que la DB ne partage pas le disque avec des jobs bruyants.

5) Symptom : staging est rapide, production est lente

Cause racine : le dataset de staging est minuscule ; la production a de grosses tables meta et une cardinalité différente.

Fix : Tester avec des données proches de la production ; utiliser EXPLAIN ANALYZE sur de vraies formes de requête ; éviter de prendre des décisions de perf sur des données jouets.

6) Symptom : « On a ajouté Redis et rien n’a changé »

Cause racine : la partie lente est une grosse requête unique, pas des lookups répétables ; ou le cache est flushé/désactivé pour l’admin.

Fix : Valider les slow query logs ; s’assurer que le cache objet persistant est activé ; arrêter le gros scan ; ne pas attendre du cache qu’il corrige des filtres non indexés.

7) Symptom : Après ajout d’index, les écritures ont ralenti

Cause racine : Trop d’index secondaires sur des tables chaudes ; le maintien des index pèse sur les écritures.

Fix : Supprimer les index de faible valeur ; ne garder que ceux qui servent les patterns principaux ; envisager un changement de schéma (HPOS) plutôt que d’indexer à outrance l’EAV.

8) Symptom : 504s aléatoires alors que certaines requêtes passent

Cause racine : PHP-FPM max children atteint ; mise en file sous charge ; appels DB lents tenant les workers.

Fix : Identifier les appels bloquants via slowlog/APM ; corriger le DB ; éventuellement scinder le pool admin ; ajuster les timeouts en dernier recours.

Listes de contrôle / plan pas à pas

Checklist A : Triage d’urgence (même jour)

1. Confirmer la latence de l’endpoint via les logs d’accès et curl TTFB côté serveur.
2. Vérifier la saturation PHP-FPM (status) : êtes-vous à max children ?
3. Activer PHP-FPM slowlog à 5s pour une courte fenêtre ; reproduire une fois.
4. Activer MySQL slow query log à 1s pendant 10–15 minutes ; reproduire une fois.
5. Exécuter pt-query-digest ; choisir la requête top par temps total et lignes examinées.
6. Exécuter EXPLAIN / EXPLAIN ANALYZE sur la requête exacte ; screenshot/sauvegarder la sortie.
7. Si vous voyez un LIKE wildcard sur meta_value : restreindre immédiatement cette recherche (politique/UX), ou désactiver ce filtre temporairement.
8. Si vous voyez des lock waits : identifier le bloqueur dans PROCESSLIST et arrêter/replanifier le job fautif.

Checklist B : Correctifs structurels (1–2 semaines)

1. Décider de l’adoption de HPOS. Si oui, faire des tests de compatibilité et un plan de migration avec rollback.
2. Auditer les plugins qui hookent la liste Commandes : supprimer colonnes et filtres non essentiels.
3. Ajouter seulement les index justifiés par les digests principaux (et valider l’impact sur les écritures).
4. Dimensionner correctement le buffer pool MySQL ; valider l’absence de swap.
5. Limiter Action Scheduler et autres jobs en arrière-plan ; définir des alertes sur la profondeur des queues.
6. Assurer la stabilité du cache objet persistant (pas de flush fréquent) et surveiller le hit/miss.

Checklist C : Garder la rapidité (en continu)

1. Collecter les digests slow query hebdomadairement (fenêtre courte), comparer les tendances.
2. Tester la performance sur des données proches de la production pour tout plugin ou mise à jour WooCommerce.
3. Définir un « SLO admin » (ex. Orders list p95 < 2s) et alerter en cas de violation.
4. Documenter tout index ajouté et les patterns de requête qu’il sert.

FAQ

1) Pourquoi l’admin WooCommerce est lent alors que la vitrine est fluide ?

Les pages storefront sont cacheables et souvent servies depuis un cache de page/CDN. Les pages admin sont personnalisées, non cacheables,
et exécutent des requêtes plus lourdes (filtres, tris, comptages, lookups meta, vérifications de capacités).

2) Le principal coupable est-il généralement wp_postmeta ?

Souvent, oui—surtout pour la recherche et le filtrage des commandes. La combinaison de nombreuses lignes, d’un schéma flexible,
et de patterns non indexés fait de wp_postmeta un récidiviste à l’échelle.

3) Dois-je simplement activer le cache objet Redis ?

Activez-le si vous pouvez le faire correctement (persistant, monitoré, dimensionné). Mais il ne réparera pas une requête unique lente
qui scanne des millions de lignes meta. Traitez le cache objet comme un multiplicateur pour des patterns de requête déjà raisonnables.

4) Puis-je résoudre la lenteur admin en augmentant les workers PHP-FPM ?

Parfois ça réduit la mise en file, mais cela peut aussi aggraver le problème DB en envoyant plus de requêtes lentes concurrentes.
Corrigez d’abord les appels DB bloquants, puis ajustez la concurrence.

5) Quelle est la façon la plus rapide d’identifier la requête lourde ?

Activez le slow query log MySQL avec un seuil à 1s pendant 10–15 minutes pendant une fenêtre de reproduction, puis lancez pt-query-digest.
Suivez avec EXPLAIN/EXPLAIN ANALYZE sur le digest principal.

6) Les index sur meta_value valent-ils jamais le coup ?

Rarement pour les recherches « contains », car les wildcards en tête ne peuvent pas utiliser l’index. Les index préfixes aident pour les correspondances exactes/préfixes,
mais ils ajoutent un coût d’écriture. N’ajoutez-les que lorsqu’un pattern principal l’exige et après avoir testé l’impact sur les écritures.

7) Concrètement, comment HPOS aide-t-il ?

HPOS place les champs de commande fréquemment filtrés/tris dans des colonnes dédiées avec des index appropriés, réduisant les jointures meta et améliorant
les choix du planner. Il transforme « scanner le meta et espérer » en « utiliser un index et récupérer des lignes ».

8) Pourquoi je vois « Using temporary; Using filesort » dans EXPLAIN ?

Cela signifie que MySQL crée un jeu de résultats temporaire et le trie au lieu d’utiliser l’ordre d’un index.
C’est courant quand ORDER BY ne correspond pas à un index, ou quand les joins/filtres empêchent la récupération ordonnée par index.
La correction est une meilleure sélectivité, des index composites appropriés, ou des formes de requête/schémas différents.

9) Dois-je séparer le serveur de base de données du serveur web ?

Si vous êtes à une échelle significative, oui : cela réduit les effets de voisins bruyants et facilite le réglage de l’I/O et de la mémoire.
Mais n’utilisez pas l’architecture comme substitut à la correction des requêtes pathologiques. Vous aurez juste une facture plus grosse et le même scan.

10) Et si la requête lente vient d’un plugin que je ne peux pas retirer ?

D’abord, désactivez l’intégration du plugin à la liste Commandes si possible (colonnes, filtres, appels live). Ensuite, capturez les requêtes exactes
et envoyez-les au fournisseur avec la sortie EXPLAIN. Enfin, isolez la fonctionnalité sur une page séparée ou déplacez-la en tâche asynchrone.

Conclusion : prochaines étapes à livrer cette semaine

Si votre écran Commandes WooCommerce est lent, cessez de le traiter comme un mystère non résolu.
Capturez la requête lente, lisez le plan, et faites en sorte que la requête cesse de scanner l’univers.

1. Collecter des preuves : slow query log (seuil 1s) + pt-query-digest + EXPLAIN pour la requête principale.
2. Supprimer les pires patterns dictés par l’UX : recherches wildcard meta, colonnes excessives, filtres coûteux.
3. Corriger la contention : limiter imports et Action Scheduler pour que le travail admin ne concurrence pas les écritures batch.
4. Prendre une décision structurelle : adoption de HPOS si vous avez beaucoup de commandes et êtes encore sur le stockage legacy.
5. Puis tuner : dimensionnement du buffer pool, stabilité du cache objet, et concurrence PHP-FPM—après que le SQL soit sain.

La performance admin, c’est la performance opérationnelle. Si votre personnel ne peut pas expédier, rembourser, ou répondre aux clients rapidement,
l’entreprise est en panne même si la page d’accueil charge.