MariaDB 11.8 arrive avec des améliorations importantes en termes de performance, d’optimisation et de compatibilité, ainsi que de nouvelles fonctionnalités SQL et des changements internes qu’il est bon de connaître.

La nouvelle version intègre des améliorations importantes de performance, d’optimisation, de compatibilité et de nouvelles fonctionnalités SQL. Et bien que pour la plupart des sites modernes cela ne pose aucun problème, il y a quelques changements qu’il est bon de vérifier si vous travaillez avec des développements personnalisés ou des applications anciennes.

En particulier si votre projet dépend beaucoup de requêtes SQL avancées, de collations spécifiques, de procédures stockées ou de logique héritée.

La bonne nouvelle est que, dans la plupart des cas, vous n’aurez rien à toucher.

La moins bonne : si vous avez du code très ancien ou très optimisé «à la main», il vaut la peine de faire quelques vérifications.

À qui cette mise à jour de MariaDB peut-elle affecter ?

Si vous utilisez un WordPress à jour avec des plugins et thèmes habituels, vous pouvez être assez tranquille.

En général, tout continuera à fonctionner exactement de la même manière après la mise à jour.

Les cas où nous recommandons de vérifier le comportement sont :

• applications anciennes ou sans maintenance
• développements sur mesure
• intégrations directes avec MariaDB
• requêtes SQL complexes
• configurations anciennes de charset ou de collation
• triggers et procédures stockées
• systèmes avec réplication ou intégrations externes

En d’autres termes : plus le projet est personnalisé, plus il est recommandé de valider certains points.

Le changement le plus important : utf8mb4 devient le charset par défaut ⚠️

L’un des changements les plus pertinents de MariaDB 11 est que le charset par défaut n’est plus latin1 mais devient utf8mb4.

Et oui : cela importe plus qu’il n’y paraît.

Pourquoi cela peut-il affecter ?

Parce que de nombreuses applications anciennes n’ont jamais défini explicitement le charset de leurs tables ou colonnes.

Elles supposaient simplement la valeur par défaut du serveur.

Avec MariaDB 11, cela change.

Qu’est-ce qui peut commencer à se comporter différemment ?

Principalement :

• comparaisons de texte
• recherches
• tri (ORDER BY)
• groupements (GROUP BY)
• égalité entre chaînes
• traitement des caractères spéciaux ou emojis

Dans certains projets, cela n’aura aucun impact.

Dans d’autres, en particulier les applications anciennes ou multilingues, cela peut provoquer des différences visibles.

Alors, que convient-il de vérifier ?

En particulier :

• tables créées il y a des années
• colonnes sans charset explicite
• applications qui mélangent différentes collations
• logique dépendante de l’ordre exact des résultats

Si vous souhaitez maintenir un comportement spécifique, il est recommandé de définir explicitement le charset et la collation dans les tables et colonnes.

La collation Unicode par défaut change également

MariaDB 11.8 utilise désormais uca1400_ai_ci comme collation Unicode par défaut.

Traduit dans le monde réel : certaines comparaisons et tris de texte peuvent se comporter légèrement différemment.

Où cela se remarque-t-il généralement ?

Surtout dans :

• applications multilingues
• recherches internes
• filtres textuels
• systèmes avec tris complexes
• comparaisons entre caractères Unicode

Par exemple, des chaînes qui étaient auparavant considérées comme «égales» pourraient ne plus l’être, ou vice versa.

Ce n’est pas dramatique, mais il est recommandé de vérifier si votre application dépend beaucoup de recherches ou de comparaisons textuelles.

Les requêtes peuvent changer de comportement (même si elles fonctionnent mieux)

MariaDB 11 intègre de nombreuses améliorations dans l’optimiseur SQL.

Et cela, en général, est une bonne nouvelle.

De nombreuses requêtes s’exécutent de manière plus efficace grâce à de nouveaux critères d’optimisation et des indices plus intelligents.

Le problème est que, dans certains cas, le plan d’exécution peut changer par rapport aux versions précédentes.

Quel type de requêtes convient-il de vérifier ?

En particulier :

• UPDATE et DELETE avec sous-requêtes
• requêtes avec :
  • DATE()
  • YEAR()
  • SUBSTR()
  • UCASE()
• tables partitionnées
• colonnes virtuelles
• requêtes très optimisées manuellement

MariaDB peut désormais utiliser des indices dans des situations où il ne le pouvait pas auparavant.

En général, cela améliore la performance.

Mais si votre application dépendait d’un comportement très spécifique de l’optimiseur, il convient de le valider.

La recommandation la plus sensée

Vérifier les requêtes critiques en utilisant :

EXPLAIN
Copy

surtout si le projet a une charge importante ou une logique SQL avancée.

Les triggers et procédures stockées sont désormais plus stricts

Un autre point important : MariaDB 11 renforce certaines validations internes liées aux routines, triggers et fonctions stockées.

Qu’est-ce que cela signifie ?

Que certains anciens procédés, SQL dynamique ou syntaxe peu standard pourraient commencer à poser des problèmes lors de leur recréation ou validation.

De plus, les triggers UPDATE peuvent désormais s’exécuter uniquement lorsque certaines colonnes changent.

Cela ouvre de nouvelles possibilités, mais peut également changer les comportements dans certains systèmes hérités.

Devriez-vous vous inquiéter ?

Seulement si vous utilisez :

• procédures stockées complexes
• triggers personnalisés
• SQL dynamique
• logique ancienne maintenue depuis des années

Dans les applications modernes ou CMS habituels, cela ne pose généralement pas de problème.

Certaines anciennes variables disparaissent ou deviennent obsolètes

Comme c’est le cas dans presque tout saut de version important, MariaDB 11 élimine une partie de la compatibilité héritée.

Certaines variables déjà supprimées

• old_alter_table
• wsrep_load_data_splitting
• anciennes variables de OQGraph

Variables obsolètes

• tx_isolation
• spider_casual_read

Que devriez-vous vérifier

Surtout :

• scripts d’automatisation
• configurations personnalisées
• outils internes
• déploiements anciens

Souvent, le problème ne réside pas dans l’application web, mais dans des scripts oubliés qui continuent d’utiliser une syntaxe ancienne.

MariaDB 11 apporte également des améliorations intéressantes

Tout n’est pas question de compatibilités et de révisions 😄

La nouvelle version ajoute également des fonctionnalités assez puissantes.

Nouvelles fonctions UUID

Vous pouvez maintenant utiliser :

UUID_v4()
UUID_v7()Copy

directement depuis MariaDB.

Améliorations en JSON

MariaDB continue d’améliorer considérablement le support JSON avec des fonctions telles que :

• JSON_SCHEMA_VALID()
• JSON_ARRAY_INTERSECT()
• JSON_OBJECT_FILTER_KEYS()

très utiles dans les applications modernes et les APIs.

Fonctions vectorielles et recherche sémantique

Oui : MariaDB commence également à entrer dans le monde de l’IA.

La nouvelle version intègre :

• types vectoriels
• indices vectoriels
• fonctions de similarité

orientées vers les recherches sémantiques et les applications modernes liées aux embeddings ou à l’IA.

Alors… devriez-vous faire quelque chose ?

Pour la plupart des projets : probablement pas.

Si vous utilisez des applications modernes, des CMS habituels ou des logiciels à jour, il est normal que la migration soit complètement transparente.

Où nous recommandons de vérifier, c’est dans les projets :

• anciens
• très personnalisés
• avec SQL avancé
• avec logique héritée
• avec intégrations directes contre MariaDB

Dans ces cas, il vaut la peine de valider :

• collations
• requêtes critiques
• triggers
• procédures stockées
• configurations anciennes

Si vous voulez être sûr, une bonne pratique est de tester préalablement l’application dans des environnements de staging avant la mise à jour définitive, surtout dans les projets critiques ou avec beaucoup de développement sur mesure.