Optimiser les performances de votre boutique PrestaShop : des requêtes SQL au cache de page

Chaque requête compte : pourquoi la performance de la base de données est le goulot d’étranglement caché de votre boutique

J’ai audité plus de 200 boutiques PrestaShop au cours des cinq dernières années. À chaque fois — sans exception — le plus gros gain de performance provient de la couche base de données. Pas d’un CDN. Pas de la compression d’images. Pas d’un énième plugin de cache. La base de données.

Un chargement de page PrestaShop typique exécute entre 80 et 300 requêtes SQL. Sur une boutique avec 10 000+ produits, ce nombre peut dépasser 500 sur les pages de catégories avec navigation à facettes. Quand seulement quelques-unes de ces requêtes prennent 200ms au lieu de 2ms, votre Time to First Byte (TTFB) explose, votre CPU serveur s’affole et votre taux de conversion chute. Les recherches de Google montrent qu’une augmentation de 100ms du temps de chargement réduit les conversions jusqu’à 7%.

Cet article n’est pas un aperçu générique « accélérez PrestaShop ». Je vais approfondir la performance de la base de données — identifier les requêtes lentes, comprendre les plans d’exécution, tuner InnoDB, choisir les bons index et nettoyer la surcharge de données qui tue silencieusement votre boutique. Si vous avez déjà lu notre guide général de performance, considérez ceci comme le chapitre suivant.

Étape 1 : Activer le Slow Query Log — votre meilleur outil de diagnostic

Avant d’optimiser quoi que ce soit, vous devez voir ce qui est réellement lent. Le slow query log de MySQL enregistre chaque requête qui dépasse un seuil de temps que vous définissez. J’ai perdu le compte des propriétaires de boutiques qui sautent cette étape pour passer directement à « ajouter Redis » — c’est comme prendre des antidouleurs sans diagnostiquer la blessure.

Activer le Slow Query Log

Ajoutez ces lignes à votre fichier de configuration MySQL ou MariaDB (généralement /etc/mysql/mysql.conf.d/mysqld.cnf ou /etc/mysql/mariadb.conf.d/50-server.cnf) :

# Enable slow query logging
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-query.log
long_query_time = 0.5
log_queries_not_using_indexes = 1
min_examined_row_count = 100

Les paramètres clés :

• long_query_time = 0.5 — Enregistre toute requête prenant plus de 500ms. La valeur par défaut de 10 secondes est absurdement élevée pour le e-commerce ; quand une requête met 10 secondes, votre client est parti depuis 8 secondes.
• log_queries_not_using_indexes = 1 — Capture les requêtes faisant des full table scans même si elles sont rapides sur de petits jeux de données. Ce sont des bombes à retardement qui explosent quand votre catalogue grandit.
• min_examined_row_count = 100 — Filtre les requêtes triviales pour que votre log reste concentré sur les vrais problèmes.

Après l’activation, redémarrez MySQL et laissez-le collecter des données pendant au moins 24 heures couvrant un cycle de trafic complet. Puis analysez :

# Summarize the worst offenders
mysqldumpslow -s t -t 20 /var/log/mysql/slow-query.log

# Or use pt-query-digest from Percona Toolkit for deeper analysis
pt-query-digest /var/log/mysql/slow-query.log > /tmp/query-report.txt

pt-query-digest du Percona Toolkit est la référence ici. Il regroupe les requêtes similaires, les classe par temps d’exécution total et vous montre exactement où votre base de données passe son temps. Installez-le — il est gratuit et disponible dans la plupart des gestionnaires de paquets.

Étape 2 : Lire les plans EXPLAIN — la compétence qui sépare la supposition de la connaissance

Une fois que vous avez identifié vos requêtes lentes, l’étape suivante est de comprendre pourquoi elles sont lentes. La commande EXPLAIN de MySQL vous montre le plan d’exécution de la requête — comment l’optimiseur décide de récupérer vos données.

EXPLAIN SELECT p.id_product, pl.name, p.price
FROM ps_product p
LEFT JOIN ps_product_lang pl ON p.id_product = pl.id_product AND pl.id_lang = 1
LEFT JOIN ps_category_product cp ON p.id_product = cp.id_product
WHERE cp.id_category = 42 AND p.active = 1
ORDER BY p.date_add DESC;

Ce qu’il faut rechercher dans la sortie

La sortie EXPLAIN idéale montre type: ref ou type: eq_ref, un key spécifique utilisé et une estimation rows basse. Quand vous voyez type: ALL combiné avec Using temporary; Using filesort, vous avez trouvé une requête qui fait le maximum de travail pour un minimum de résultats.

Un exemple concret PrestaShop

L’une des requêtes lentes les plus courantes que je rencontre dans les boutiques PrestaShop concerne la table ps_specific_price. Sur les boutiques avec des milliers de prix spécifiques (remises sur quantité, prix par groupe, promotions datées), ce modèle de requête apparaît constamment dans le slow log :

EXPLAIN SELECT * FROM ps_specific_price
WHERE id_product = 1542
AND id_shop IN (0, 1)
AND id_currency IN (0, 1)
AND id_country IN (0, 8)
AND id_group IN (0, 1, 3)
AND id_customer = 0
AND from_quantity >= 1
AND (from = '0000-00-00 00:00:00' OR from <= NOW())
AND (to = '0000-00-00 00:00:00' OR to >= NOW());

Sur une boutique avec 200 000+ lignes dans specific_price, cette requête examinait 180 000 lignes pour en retourner 3. La solution était un index composite :

ALTER TABLE ps_specific_price
ADD INDEX idx_product_shop_currency
(id_product, id_shop, id_currency, id_country);

Résultat : le temps de requête est passé de 340ms à 0,8ms. Sur une page de catégorie chargeant 36 produits, ce seul index a économisé 12 secondes de temps de requête cumulatif par chargement de page.

Étape 3 : Les tables les plus problématiques de PrestaShop — et comment les corriger

Après avoir analysé les slow query logs de dizaines de boutiques, ces tables sont responsables de la majorité des problèmes de performance de base de données :

ps_connections et ps_connections_page

Ces tables enregistrent chaque connexion visiteur et chaque page visitée. Sur une boutique recevant 5 000 visiteurs quotidiens consultant en moyenne 4 pages chacun, cela représente 20 000 lignes par jour — 7,3 millions de lignes par an. J’ai vu des boutiques avec 50 millions de lignes dans ps_connections_page qui n’avaient jamais été nettoyées.

-- Check the damage
SELECT table_name, table_rows,
  ROUND(data_length/1024/1024, 2) AS data_mb,
  ROUND(index_length/1024/1024, 2) AS index_mb
FROM information_schema.tables
WHERE table_schema = 'prestashop'
AND table_name IN ('ps_connections', 'ps_connections_page',
  'ps_log', 'ps_mail', 'ps_guest', 'ps_pagenotfound');

-- Clean old connection data (keep 90 days)
DELETE FROM ps_connections_page
WHERE id_connections IN (
  SELECT id_connections FROM ps_connections
  WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY)
);
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);

-- Clean old logs (keep 30 days)
DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Clean sent emails log (keep 60 days)
DELETE FROM ps_mail WHERE date_add < DATE_SUB(NOW(), INTERVAL 60 DAY);

-- Clean 404 tracking (keep 30 days)
DELETE FROM ps_pagenotfound WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

Important : Après de grosses suppressions, récupérez l’espace disque :

OPTIMIZE TABLE ps_connections, ps_connections_page, ps_log, ps_mail, ps_guest;

ps_cart et ps_cart_product

Les paniers abandonnés s’accumulent indéfiniment. Une boutique de 5 ans peut avoir 2 millions d’enregistrements de paniers avec 8 millions de lignes cart_product, dont 95% ne se convertiront jamais. Nettoyez les paniers de plus de 6 mois qui n’ont aucune commande associée :

-- Identify orphan carts (no order placed)
DELETE cp FROM ps_cart_product cp
INNER JOIN ps_cart c ON cp.id_cart = c.id_cart
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
WHERE o.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 180 DAY);

DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
WHERE o.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 180 DAY);

ps_search_index et ps_search_word

L’index de recherche de produits peut devenir énorme sur les gros catalogues. Après un nettoyage de produits ou des mises à jour massives, reconstruisez-le :

-- Nuclear option: truncate and rebuild
TRUNCATE TABLE ps_search_index;
TRUNCATE TABLE ps_search_word;

-- Then trigger a full reindex via CLI:
php bin/console prestashop:search:reindex

Étape 4 : Stratégie d’indexation pour les tables des modules PrestaShop

Si vous développez des modules — ou utilisez des modules tiers qui créent des tables personnalisées — l’indexation est de votre responsabilité. Les tables core de PrestaShop sont livrées avec des index raisonnables, mais les tables de modules n’en ont fréquemment aucun.

Principes pour une indexation efficace

1. Indexez les colonnes utilisées dans les clauses WHERE — Si votre module fait des requêtes WHERE id_product = X AND id_shop = Y, créez un index composite sur (id_product, id_shop).
2. L’ordre des colonnes compte dans les index composites — Placez la colonne la plus sélective en premier. Une colonne avec 10 000 valeurs uniques doit précéder une avec 3 valeurs uniques.
3. Couvrez votre ORDER BY — Si vous triez fréquemment par date_add DESC, incluez date_add dans l’index pour éviter les opérations filesort.
4. N’indexez pas trop — Chaque index ralentit les opérations INSERT et UPDATE. Pour une table à forte écriture (comme une table de logs), réfléchissez bien avant d’ajouter des index.

-- Example: module review table with common query patterns
CREATE TABLE ps_mymodule_reviews (
  id_review INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  id_product INT UNSIGNED NOT NULL,
  id_customer INT UNSIGNED NOT NULL,
  id_shop INT UNSIGNED NOT NULL DEFAULT 1,
  rating TINYINT UNSIGNED NOT NULL,
  status TINYINT NOT NULL DEFAULT 0,
  date_add DATETIME NOT NULL,

  -- Composite index for "show approved reviews for product X"
  INDEX idx_product_status (id_product, status, date_add),

  -- Index for "show all reviews by customer"
  INDEX idx_customer (id_customer),

  -- Index for admin list with shop filter
  INDEX idx_shop_status (id_shop, status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Trouver les index manquants sur les tables existantes

-- List all module tables without non-primary indexes
SELECT t.table_name, t.table_rows
FROM information_schema.tables t
LEFT JOIN information_schema.statistics s
  ON t.table_name = s.table_name
  AND t.table_schema = s.table_schema
  AND s.index_name != 'PRIMARY'
WHERE t.table_schema = 'prestashop'
AND t.table_name LIKE 'ps_%'
AND t.table_rows > 1000
AND s.index_name IS NULL
ORDER BY t.table_rows DESC;

Cette requête révèle les tables avec plus de 1 000 lignes et aucun index secondaire — des candidates idéales pour l’optimisation.

Étape 5 : Configuration InnoDB — les paramètres qui comptent vraiment

InnoDB est le moteur de stockage de PrestaShop. Sa configuration par défaut est conçue pour une charge de travail générique sur du matériel modeste. Pour un serveur de base de données e-commerce dédié, vous devez l’ajuster.

Les paramètres critiques

[mysqld]
# === Buffer Pool: The Single Most Important Setting ===
# Set to 70-80% of available RAM on a dedicated DB server.
# For shared hosting: 50% of RAM, minimum 1GB.
innodb_buffer_pool_size = 4G

# Split the buffer pool into instances (1 per GB)
innodb_buffer_pool_instances = 4

# === Log Files: Larger = Fewer Disk Writes ===
# Default 48M is too small. Set to 25% of buffer pool, max 2G each.
innodb_log_file_size = 1G
innodb_log_buffer_size = 64M

# === Flush Behavior ===
# 1 = Full ACID (safest, slower)
# 2 = Flush to OS buffer each commit, disk write once/sec (good compromise)
# 0 = Flush once/sec (fastest, risks 1 sec of data on crash)
innodb_flush_log_at_trx_commit = 2

# Use O_DIRECT to avoid double-buffering with OS page cache
innodb_flush_method = O_DIRECT

# === I/O Capacity ===
# SSD: 2000-4000. HDD: 200-400. Cloud SSD: 1000-2000.
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000

# === Thread Concurrency ===
innodb_read_io_threads = 4
innodb_write_io_threads = 4
innodb_purge_threads = 4

# === Per-Table Tablespace (default in MySQL 5.7+, verify it's on) ===
innodb_file_per_table = 1

# === Temp Tables ===
tmp_table_size = 64M
max_heap_table_size = 64M

# === Sort and Join Buffers (per-connection, don't over-allocate) ===
sort_buffer_size = 2M
join_buffer_size = 4M
read_buffer_size = 2M
read_rnd_buffer_size = 1M

# === Connection Pool ===
max_connections = 200
thread_cache_size = 100

# === Table Cache ===
table_open_cache = 4000
table_definition_cache = 2000

# === Disable Performance Schema in Production (saves ~400MB RAM) ===
performance_schema = OFF

Comprendre innodb_buffer_pool_size

C’est le paramètre MySQL le plus impactant pour PrestaShop. Le buffer pool est l’espace où InnoDB met en cache les données des tables et les index en mémoire. Quand une requête a besoin de données déjà présentes dans le buffer pool, elles sont servies depuis la RAM au lieu du disque — un ordre de grandeur plus rapide.

Comment le dimensionner :

-- Check your total database size
SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024, 2) AS total_gb
FROM information_schema.tables
WHERE table_schema = 'prestashop';

-- Check buffer pool hit ratio (should be > 99%)
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';

-- Calculate: hit_ratio = 1 - (reads / read_requests) * 100
-- If below 99%, increase buffer_pool_size

Un benchmark réel issu des tests de Releem sur MariaDB 10.5 avec une boutique PrestaShop a montré qu’un tuning correct d’InnoDB (buffer pool dimensionné à 3,2 Go pour une base de données de 1 Go) a réduit le temps de réponse de 39% — de 610ms à 370ms — et augmenté les requêtes par seconde de 53%.

Query Cache : MariaDB vs MySQL 8

C’est un sujet souvent mal compris. MySQL 8.0 a supprimé le query cache entièrement. Oracle a déterminé que la contention de mutex du cache causait plus de problèmes qu’il n’en résolvait à grande échelle. MariaDB, en revanche, le supporte toujours et il peut aider les boutiques PrestaShop avec des charges de travail principalement en lecture.

Pour MariaDB (10.5+) :

query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 2M

Pour MySQL 8.0+ : N’essayez pas de l’activer — il n’existe plus. Comptez plutôt sur un buffer pool correctement dimensionné et envisagez le cache applicatif avec Redis.

Si vous êtes sur MySQL 8 et envisagez un changement, MariaDB 10.11 est entièrement compatible avec PrestaShop et de nombreux hébergeurs le proposent en remplacement direct.

Étape 6 : Modèles de requêtes spécifiques à PrestaShop à surveiller

Au-delà du tuning général de MySQL, PrestaShop a des modèles de requêtes spécifiques qui causent des problèmes de performance à grande échelle. Voici ceux que je rencontre le plus fréquemment :

Le problème du comptage de produits

La navigation à facettes de PrestaShop (recherche facettée) exécute des requêtes COUNT pour chaque combinaison de filtres. Sur une catégorie avec 15 groupes d’attributs et 200 attributs, cela peut générer 200+ requêtes COUNT individuelles par chargement de page. Chaque requête semble innocente :

SELECT COUNT(DISTINCT p.id_product)
FROM ps_product p
INNER JOIN ps_product_attribute_combination pac ...
WHERE ... AND pac.id_attribute = 47;

Mais 200 d’entre elles à 10ms chacune égalent 2 secondes de temps de requête pur. La solution est soit d’utiliser une table d’index pré-calculé (que des modules comme nos modules SEO et performance peuvent fournir), soit de réduire les filtres visibles via la configuration de la catégorie.

Le problème N+1 dans les hooks de modules

Un module enregistré sur displayProductListReviews qui exécute une requête par produit crée un problème N+1. Si votre page de catégorie affiche 36 produits, cela représente 36 requêtes supplémentaires — par module :

// Bad: query per product in a list hook
public function hookDisplayProductListReviews($params) {
    $id_product = (int)$params['product']['id_product'];
    $result = Db::getInstance()->getRow(
        'SELECT AVG(rating) as avg_rating
         FROM ps_mymodule_reviews
         WHERE id_product = ' . $id_product
    );
    // ...
}

// Good: batch query all products at once, cache the result
public function hookActionProductSearchAfter($params) {
    $products = $params['result']->getProducts();
    $ids = array_column($products, 'id_product');

    $ratings = Db::getInstance()->executeS(
        'SELECT id_product, AVG(rating) as avg_rating
         FROM ps_mymodule_reviews
         WHERE id_product IN (' . implode(',', array_map('intval', $ids)) . ')
         GROUP BY id_product'
    );
    // Store in static cache for use in display hook
}

Évaluation des règles panier

Les boutiques avec des centaines de règles panier actives souffrent à chaque chargement de page panier. Les conditions de chaque règle panier (restrictions de produits, restrictions de catégories, groupes de clients) déclenchent des requêtes séparées. Si vous avez plus de 50 règles panier actives, envisagez :

• D’archiver les règles expirées (définissez leur active à 0 et date_to à une date passée)
• De consolider les règles qui se chevauchent quand c’est possible
• D’ajouter un index sur ps_cart_rule.active, ps_cart_rule.date_from, ps_cart_rule.date_to

Étape 7 : Surveillance en production — ne configurez pas et n’oubliez pas

Le tuning de base de données n’est pas une tâche ponctuelle. Les données de votre boutique grandissent, les patterns de trafic évoluent et les mises à jour de modules peuvent introduire de nouveaux modèles de requêtes. Mettez en place une surveillance continue :

Métriques essentielles à suivre

-- Buffer pool efficiency (check weekly)
SELECT
  FORMAT(VARIABLE_VALUE, 0) AS buffer_pool_read_requests
FROM performance_schema.global_status
WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests';

-- Slow queries per hour (should trend downward)
SHOW GLOBAL STATUS LIKE 'Slow_queries';

-- Table lock waits (should be near zero for InnoDB)
SHOW GLOBAL STATUS LIKE 'Table_locks_waited';

-- Temporary tables created on disk (high = increase tmp_table_size)
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';

-- Thread connection usage
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Surveillance automatisée

Pour les boutiques où une indisponibilité signifie une perte de chiffre d’affaires réelle, envisagez ces solutions de surveillance :

• Percona Monitoring and Management (PMM) — Gratuit, open source, tableaux de bord complets pour MySQL/MariaDB avec analytique de requêtes. C’est ce que j’utilise pour toutes les boutiques de mes clients.
• Releem — Tuning automatisé de MySQL qui ajuste les paramètres en fonction de votre charge de travail réelle. Utile si vous ne souhaitez pas tuner manuellement my.cnf.
• MySQLTuner — Un script Perl qui fournit des recommandations rapides : perl mysqltuner.pl --host 127.0.0.1

Étape 8 : Quand ajouter Redis — et ce qu’il résout réellement

Redis n’est pas un substitut à l’optimisation de la base de données. C’est une couche par-dessus. Si vos requêtes sous-jacentes sont lentes, Redis masque le problème pour les requêtes en cache et l’aggrave quand le cache expire (effet de troupeau).

Après avoir optimisé vos index, nettoyé vos tables et ajusté InnoDB — alors ajoutez Redis pour :

• Le stockage des sessions — Élimine le verrouillage de fichiers lors des requêtes concurrentes. Configurez dans config/defines.inc.php ou utilisez le handler de session Symfony.
• Le cache Smarty — Empêche Smarty d’écrire des milliers de fichiers de templates compilés sur disque.
• Le cache Symfony — Métadonnées Doctrine, routage et caches du conteneur de services servis depuis la mémoire.
• Le cache au niveau des modules — Toute donnée de module coûteuse à calculer mais qui change rarement.

Le résultat : sur une boutique correctement optimisée, l’ajout de Redis réduit généralement le TTFB de 30-50% supplémentaires. Notre guide de performance couvre la configuration de Redis en détail.

Étape 9 : Full Page Cache — la couche finale

Une fois que votre base de données est allégée et que votre cache applicatif est dans Redis, l’optimisation ultime est d’éliminer entièrement l’exécution PHP pour les visiteurs anonymes. Varnish ou le cache FastCGI de nginx peuvent servir une page entièrement rendue en moins de 10ms — comparé à 200-500ms pour une page rendue par PHP.

Le défi avec PrestaShop est l’invalidation du cache. Les changements de prix, les mises à jour de stock, les débuts/fins de promotions et les modifications de panier nécessitent tous soit :

• L’invalidation par tags — Le module xkey de Varnish permet de taguer les pages en cache par produit, catégorie ou page CMS et de les purger sélectivement.
• L’approche par TTL — Mettez les pages en cache pendant 5-15 minutes et acceptez une brève obsoléscence. Convient à la plupart des boutiques où la précision du stock à la seconde n’est pas critique.
• L’approche hybride — Mettez en cache le squelette de la page, utilisez ESI (Edge Side Includes) ou JavaScript pour les fragments dynamiques comme le widget panier et le statut de connexion.

Pour les boutiques à fort trafic, la combinaison base de données optimisée + cache applicatif Redis + Varnish FPC atteint couramment un TTFB inférieur à 50ms. L’un de nos clients avec un catalogue de 15 000 produits est passé d’un TTFB de 800ms à 120ms en utilisant exactement cette stack.

L’ordre de priorité : impact maximal, risque minimal

Si vous ne retenez qu’une chose de cet article, c’est cette liste de priorités :

1. Activez le slow query log et corrigez les 10 pires requêtes — Impact immédiat, zéro coût, aucun risque.
2. Nettoyez les tables surchargées — ps_connections, ps_log, ps_mail, paniers abandonnés. Récupération immédiate d’espace et de performance.
3. Ajustez le buffer pool InnoDB — Un seul changement de paramètre dans my.cnf, impact massif.
4. Ajoutez les index manquants sur les tables de modules — Fort impact si vous utilisez des modules gourmands en données.
5. Ajoutez Redis pour les sessions et le cache — Plancher de performance fiable, élimine le goulot d’étranglement d’I/O fichier.
6. Implémentez le full page cache — Le multiplicateur final pour les boutiques à fort trafic.

Chaque étape s’appuie sur la précédente. Sauter à l’étape 6 sans avoir fait les étapes 1-4 revient à construire sur des fondations instables.

Si vous n’êtes pas sûr de l’état de votre boutique, commencez par le slow query log. Vingt-quatre heures de données vous en diront plus que n’importe quel plugin de performance. Et si vous avez besoin d’aide pour interpréter ce que vous trouvez, contactez-nous — l’analyse de performance de base de données est l’une des choses que nous faisons le mieux.

David Miller construit des outils de performance PrestaShop et optimise des bases de données e-commerce depuis 2017. Ses modules sont disponibles sur mypresta.rocks.