MariaDB 11.4 : nouveautés, correctifs InnoDB et optimiseur

Table des matières :

1. MariaDB 11.4 : ce que cette branche apporte (vraiment) à une stack PrestaShop
2. Correctifs InnoDB : verrous, crash-safety et I/O sous charge e‑commerce
3. Optimiseur MariaDB 11.4 : pourquoi vos requêtes « identiques » changent de coût
4. Migration vers MariaDB 11.4 : procédure safe, contraintes, et rollback réaliste
5. Après upgrade : observabilité, régressions typiques, et tuning qui a un ROI

MariaDB 11.4 : ce que cette branche apporte (vraiment) à une stack PrestaShop

MariaDB 11.4 vise un usage production long-courrier (et pas juste une release « feature »). Pour une boutique PrestaShop, l’intérêt n’est pas d’« avoir la dernière version », mais de réduire le risque opérationnel : correctifs de stabilité sur InnoDB, ajustements de l’optimiseur, et une base plus saine pour tenir la charge (trafic, imports, jobs cron, moteurs de recherche, ERP). La conséquence pratique : vous migrez moins souvent, mais vous migrez mieux, parce que vous avez une fenêtre de support et un rythme de correctifs exploitable en prod.

Côté compatibilité, PrestaShop (8.x / 9.x) parle « MySQL dialect » via PDO, donc la plupart des changements se jouent sur : (1) le comportement SQL (modes, collations, conversions implicites), (2) le plan d’exécution choisi par l’optimiseur, (3) les verrous et latences d’I/O dans InnoDB. Si vous avez un checkout lent ou des pages catégorie qui se dégradent avec les filtres, vous le verrez après upgrade même si « le code n’a pas changé ». C’est précisément ce qu’il faut tester : mêmes requêtes, nouveaux plans.

Deux points souvent sous-estimés en e-commerce (et encore plus en période de pics type soldes/Black Friday) :

• Une migration DB change la “forme” de la perf, pas seulement le niveau : une requête peut rester à 80 ms en médiane mais exploser au p95/p99 si le plan se met à lire davantage de lignes ou si la contention augmente.
• La compatibilité dépend aussi de l’OS et de PHP : avant de décider “MariaDB 11.4 partout”, validez que votre couple PrestaShop / PHP / extensions (PDO MySQL, intl, opcache…) colle bien aux prérequis officiels. Référence utile : pré-requis système PrestaShop

Pour cadrer proprement : partez d’un environnement Debian 12/Ubuntu LTS, PHP 8.2 ou 8.3 (typiques en 2026), PrestaShop 8.1+ ou 9.x, et MariaDB 11.4.x. Montez d’abord un staging fidèle (même dataset, mêmes paramètres MariaDB) ; l’article Staging PrestaShop : créer un environnement Docker fidèle à la production est un bon point d’entrée pour industrialiser la pré-prod.

Pour rendre ce staging réellement “parlant”, évitez le piège du dataset miniature. Un protocole simple qui donne de bons résultats :

• restaurez un dump anonymisé ou un clone complet (si RGPD/contrats OK) ;
• rejouez un trafic synthétique (navigation catégorie + recherche + ajout panier + checkout) ;
• lancez vos crons (indexations, synchronisations ERP, exports) sur les mêmes plages horaires que la prod ;
• comparez p95/p99 des pages clés et les top requêtes lentes avant/après.

Correctifs InnoDB : verrous, crash-safety et I/O sous charge e‑commerce

Dans la pratique, les correctifs InnoDB qui comptent en e-commerce ne sont pas « visibles » dans un changelog marketing : ils se traduisent par moins de contention (temps d’attente sur verrous), moins de stalls I/O, et une récupération plus prévisible après incident. Sur PrestaShop, les hotspots classiques sont : écriture concurrente sur ps_orders, ps_order_detail, ps_cart, ps_cart_product, mise à jour de ps_stock_available, et recalculs de prix/indexations déclenchés par modules. Une boutique avec forte concurrence sur le panier peut basculer en spirale si le lock wait s’allonge (p95 qui explose, threads qui s’empilent, back-office qui time-out).

Mini-scénario (très réaliste) : une boutique FR sur VPS “correct” tient 50 checkouts/minute sans souci… jusqu’au moment où un module de statistiques écrit un log par événement (page view + add to cart + paiement). Résultat : mêmes tables, plus de writes, et des transactions plus longues → InnoDB garde les verrous plus longtemps, les autres sessions attendent, et vous observez un embouteillage côté PHP-FPM. Dans ce cas, MariaDB 11.4 peut améliorer la stabilité, mais le vrai levier reste : réduire la durée des transactions et supprimer les écritures inutiles (ou les basculer vers une file/outil dédié).

Le réglage « réel » se fait avec de la mesure. Trois axes à auditer avant/après passage en MariaDB 11.4 :

• Buffer pool : si Innodb_buffer_pool_reads augmente et que vos I/O disques sont déjà proches de la saturation, vous avez un problème de mémoire utile.
• Verrous : Innodb_row_lock_time et Innodb_row_lock_waits (corrélés aux endpoints checkout / module paiement).
• Write path : flush et fsync, particulièrement si vous êtes sur VPS mutualisé avec I/O instables.

Pour interpréter plus vite, une grille de lecture simple :

Signal	Ce que ça suggère	Action typique (avant de “tuner”)
Innodb_buffer_pool_reads monte	cache insuffisant, lecture disque	augmenter buffer pool, vérifier que RAM est disponible (pas swap), réduire full scans
Innodb_row_lock_waits monte	contention applicative (transactions longues)	traquer requêtes UPDATE/INSERT lentes, réduire durée de transaction, ajouter index sur colonnes filtrées
SHOW ENGINE INNODB STATUS montre beaucoup de “history list length”	purge en retard (undo) / charge write élevée	réduire charge write, vérifier I/O, revoir jobs batch et modules “loggants”

Exemples de commandes (à exécuter en session d’observation, sans « tuning au hasard ») :

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool%';
SHOW GLOBAL STATUS LIKE 'Innodb_row_lock%';
SHOW ENGINE INNODB STATUS\G

Et côté configuration (exemple indicatif, à adapter à votre RAM et à votre profil d’I/O) :

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
innodb_buffer_pool_size = 8G   # viser ~60-70% de la RAM sur serveur DB dédié
innodb_flush_log_at_trx_commit = 1  # ACID strict (2 si vous acceptez un risque de perte < 1s)
innodb_flush_method = O_DIRECT
innodb_io_capacity = 1000
innodb_io_capacity_max = 2000

Deux précautions “prod” utiles (surtout si vous faites de la réplication ou des sauvegardes à chaud) :

• Ne changez pas plusieurs paramètres structurants à la fois (buffer pool + flush + I/O capacity + taille des logs) : vous ne saurez pas ce qui a aidé ou cassé.
• Si vous activez le binaire log (binlog) pour réplication/point-in-time recovery, gardez une cohérence ACID : innodb_flush_log_at_trx_commit=1 a du sens, mais c’est à mettre en face de votre stockage (NVMe vs SSD SATA vs réseau).

Point dur : PrestaShop n’a pas une discipline « write-optimized » dans le core, et certains modules amplifient les écritures (logs, stats, historiques). Si vous êtes sur hébergement OVH/VPS, les gains InnoDB peuvent être invisibles tant que le goulot est l’I/O ou l’architecture ; cf. Serveur dédié PrestaShop : config Nginx PHP-FPM MariaDB Redis

Optimiseur MariaDB 11.4 : pourquoi vos requêtes « identiques » changent de coût

Le sujet que beaucoup sous-estiment : l’optimiseur. Vous pouvez upgrader MariaDB, ne toucher à aucun index, et constater une régression sur une page catégorie ou sur une requête de recherche. Ce n’est pas magique : de nouvelles heuristiques, des ajustements d’estimation de cardinalité, ou des changements de stratégie de jointure peuvent faire basculer un plan. Et l’optimisation « à l’instinct » est un piège classique ; Donald Knuth résume parfaitement le danger : « Premature optimization is the root of all evil. » (Donald E. Knuth, 1974). La version « prod » de cette phrase : measure first, tune second.

Pour du PrestaShop, les anti-patterns qui interagissent mal avec l’optimiseur sont récurrents :

• JOINs larges + WHERE peu sélectif sur des tables shop/lang (ex. ps_product_shop, ps_product_lang) ;
• ORDER BY + LIMIT sans index compatible (tri sur colonnes non couvertes) ;
• Pagination coûteuse (OFFSET élevé) ;
• Filtres à facettes qui créent des ensembles intermédiaires énormes (le module ps_facetedsearch est un suspect régulier ; et en 2026, il reste facile à mettre à genoux sur gros catalogues si l’indexation n’est pas maîtrisée).

Sur MariaDB 11.4, votre routine doit être : capturer les requêtes lentes, comprendre le plan, puis décider. Utilisez EXPLAIN systématiquement, et comparez avant/après migration :

EXPLAIN
SELECT p.id_product
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product AND ps.id_shop = 1
WHERE ps.active = 1
ORDER BY ps.date_upd DESC
LIMIT 60;

Ce que vous cherchez : type (ALL vs range/ref), rows (estimation), possible_keys vs key réellement choisie, et l’Extra (Using filesort est souvent synonyme de tri hors index). Si le plan s’est dégradé après MariaDB 11.4, le correctif est rarement « changer de version » : c’est ajouter l’index composite qui correspond au WHERE + ORDER, ou réécrire une requête (ex. split en deux requêtes, dénormaliser un champ, réduire l’ensemble trié).

Un pattern d’index qui aide très souvent sur ce type de liste (à valider sur votre schéma exact et vos requêtes réelles) : un index composite commençant par les colonnes de filtrage (id_shop, active) puis la colonne de tri (date_upd), afin que l’engine puisse sortir les 60 lignes sans trier un gros ensemble. L’idée n’est pas de “mettre des index partout”, mais de coller à la requête dominante (celle que l’utilisateur déclenche 1000 fois/jour).

Autre point concret après upgrade : si vous avez importé massivement (catalogue, déclinaisons, prix spécifiques) ou si vous migrez en Blue/Green avec un restore, pensez à rafraîchir les statistiques pour éviter que l’optimiseur parte sur des estimations fausses :

ANALYZE TABLE ps_product, ps_product_shop, ps_product_lang, ps_stock_available;

La doc MariaDB sur l’optimiseur est la référence de base pour comprendre les leviers (optimizer_switch, statistiques, etc.) : doc MariaDB sur l’optimiseur

Migration vers MariaDB 11.4 : procédure safe, contraintes, et rollback réaliste

En production e-commerce, la migration est un sujet d’exploitation, pas un simple apt upgrade. Pré-requis non négociables : (1) sauvegarde validée (restore testée), (2) fenêtre de rollback, (3) staging avec charge représentative. La partie staging est souvent bâclée ; pourtant c’est là que vous détectez les changements de plans, les requêtes qui deviennent « sensibles » et les modules qui font des choses borderline. Si vous n’avez pas déjà une démarche CI/CD et environnements jetables, vous allez souffrir ; cf. PrestaShop CI/CD : générer des démos à la demande en minutes

Stratégies de migration réalistes :

1) In-place upgrade (downtime court) : acceptable si vous avez une boutique à trafic modéré et une équipe d’astreinte. Vous arrêtez l’app, faites backup, upgrade MariaDB, exécutez l’outil d’upgrade, redémarrez, puis vous surveillez.
2) Blue/Green (downtime minimal) : vous préparez un nouveau serveur MariaDB 11.4, vous répliquez (ou vous restaurez puis vous rejouez un delta), vous basculez le trafic (DNS/LB), et vous gardez l’ancien en rollback. C’est plus long, mais nettement plus sain.

Pour le rollback, soyez concret : “on remet l’ancienne VM” est une idée, pas un plan. Un rollback réaliste ressemble plutôt à :

• un ancien serveur encore opérationnel (ou snapshot exploitable),
• une procédure de bascule (LB/DNS) documentée,
• une condition d’arrêt claire (ex. « si p95 checkout > X ms pendant 15 min » ou « si erreurs SQL dépassent N/min »),
• une personne responsable de la décision (sinon, vous hésiterez trop longtemps en pleine dégradation).

Dans tous les cas, l’étape indispensable après changement de version est l’upgrade des tables système et métadonnées. Selon votre installation, la commande est généralement mariadb-upgrade (ou équivalent). Référence : MariaDB upgrade

Ensuite, check-list « compat » :

• SQL_MODE : capturez l’existant avant migration (SHOW VARIABLES LIKE 'sql_mode';) et évitez une surprise de comportement (conversions implicites, dates invalides, etc.).
• Jeux de caractères/collations : si votre base est en utf8 (3 bytes) historique, profitez de la migration pour planifier le passage en utf8mb4, mais ne le faites pas « en même temps » que l’upgrade MariaDB, sauf si vous avez du temps de QA.
• Sécurité : durcissez les comptes DB, TLS, privilèges minimaux. L’article Sécurité MySQL : pare-feu, TLS, privilèges minimaux et audit couvre l’essentiel (les principes s’appliquent à MariaDB).

Enfin, détail très opérationnel : en environnement français/européen, vous avez souvent des contraintes d’hébergement (localisation des données, interconnexions entre DC, latence réseau entre web et DB). Une migration Blue/Green est plus simple si vous gardez web et DB dans la même zone (ex. même région/cluster chez votre hébergeur), sinon vous risquez de “gagner” 10% côté InnoDB et de perdre 30% en latence réseau.

Après upgrade : observabilité, régressions typiques, et tuning qui a un ROI

Si vous ne mesurez pas, vous ne savez pas si MariaDB 11.4 vous a aidé ou non. Activez le slow query log (temporairement si besoin), et sortez des métriques actionnables : temps, fréquence, rows examined, et corrélation avec les endpoints applicatifs (catégorie, recherche, panier, checkout, BO). Exemple minimal :

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.2; -- 200ms, à ajuster

Deux raffinements qui rendent le slow log beaucoup plus exploitable en e-commerce :

• logguez aussi les requêtes non indexées le temps d’une fenêtre de mesure (attention au volume si votre site est très actif) ;
• assurez-vous que le log est écrit dans un emplacement avec assez d’espace disque, ou utilisez une rotation (sinon, vous créez votre propre incident).

Vous regroupez ensuite par fingerprint (même requête, valeurs différentes) et vous priorisez : une requête à 500 ms exécutée 10 000 fois/jour vaut plus qu’un monstre à 5 s exécuté 3 fois. Pour que la priorisation soit “business-friendly”, vous pouvez même traduire en coût :

• coût/jour ≈ durée moyenne × exécutions/jour (en secondes cumulées de DB),
• et vous mettez en face l’impact page (catégorie, recherche, checkout).

C’est exactement le genre de monitoring que vous pouvez brancher proprement avec Netdata/Prometheus côté infra ; pour la partie instrumentation et alerting, voir Netdata : intégrer Prometheus, SNMP et StatsD pour tout surveiller

Les régressions « classiques » observées après upgrade (donc à tester explicitement) :

• Pages liste (catégories/facettes) : changement de plan → Using filesort, lecture de beaucoup plus de rows.
• Checkout : contention sur tables de panier / commande → hausse Innodb_row_lock_time.
• Back-office : exports/filtrages qui déclenchent des scans complets.

Une check-list de tests “smoke” simple (et très rentable) juste après bascule :

• faire 3–5 parcours complets recherche → fiche produit → panier → paiement (avec au moins un code promo si vous en utilisez) ;
• lancer une indexation/facettes si vous en dépendez (ou un cron équivalent) ;
• exécuter un export back-office (commandes/clients) sur un intervalle réaliste ;
• vérifier que les temps de réponse DB n’explosent pas pendant les crons (sinon, vous avez un problème de concurrence/IO).

Le tuning à ROI, dans l’ordre : (1) index composites réellement alignés avec les requêtes (pas des index « décoratifs »), (2) réduction des requêtes et de leur périmètre (limiter colonnes, éviter JOIN inutiles, pagination intelligente), (3) cache applicatif et HTTP quand c’est possible (Redis, Varnish, CDN). Sur ce dernier point, relisez une stratégie cohérente côté PrestaShop (et surtout, ce que le core ne fait pas pour vous) : Cache PrestaShop : stratégie 2026 OPcache, Redis, Varnish et CDN

Enfin, si vous voulez éviter de « casser en prod », imposez un protocole : baseline (avant), migration, smoke tests, puis une fenêtre d’observation de 24–72h avec seuils (p95 page catégorie, p95 checkout, temps des top 20 requêtes DB, saturation I/O). MariaDB 11.4 peut apporter des gains réels, mais uniquement si vous traitez la DB comme un composant critique — pas comme un service « par défaut » derrière PHP.