Une nouvelle branche importante du SGBD MariaDB 11 a été introduite

10 ans après la création de la branche 10.x, MariaDB 11.0.0 a été publiée, qui offrait plusieurs améliorations et modifications significatives qui rompaient la compatibilité. La branche est actuellement en qualité de version alpha et sera prête pour une utilisation en production après stabilisation. La prochaine branche majeure de MariaDB 12, contenant des changements qui rompent la compatibilité, est attendue au plus tôt dans 10 ans (en 2032).

Le projet MariaDB développe un fork à partir de MySQL, maintenant une compatibilité ascendante autant que possible et comportant l'intégration de moteurs de stockage supplémentaires et de fonctionnalités avancées. Le développement de MariaDB est supervisé par la Fondation MariaDB indépendante, à la suite d'un processus de développement ouvert et transparent, indépendant des fournisseurs individuels. Le SGBD MariaDB est fourni à la place de MySQL dans de nombreuses distributions Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) et a été implémenté dans des projets aussi importants que Wikipedia, Google Cloud SQL et Nimbuzz.

Une amélioration clé de la branche MariaDB 11 est la transition de l'optimiseur de requêtes vers un nouveau modèle de pondération (modèle de coût), qui fournit une prédiction plus précise des pondérations de chaque plan de requête. Bien que le nouveau modèle puisse atténuer certains goulots d'étranglement en termes de performances, il peut ne pas être optimal dans tous les scénarios et ralentir certaines requêtes. Les utilisateurs sont donc encouragés à participer aux tests et à informer les développeurs si des problèmes surviennent.

Le modèle précédent était efficace pour trouver l'index optimal, mais avait des problèmes avec l'applicabilité des analyses de table, des analyses d'index ou des opérations de récupération de plage. Dans le nouveau modèle, cet inconvénient est éliminé en modifiant le poids de base des opérations avec le moteur de stockage. Lors de l'évaluation des performances des opérations dépendant de la vitesse du disque, telles que les analyses d'écriture séquentielles, nous supposons désormais que les données sont stockées sur un SSD offrant des vitesses de lecture de 400 Mo par seconde. De plus, d'autres paramètres de poids de l'optimiseur ont été ajustés, ce qui a par exemple permis d'implémenter la possibilité d'utiliser des index pour les opérations « ORDER BY/GROUP BY » dans les sous-requêtes et d'accélérer le travail avec de très petites tables.

Il est à noter que le nouveau modèle de pondération vous permettra de choisir un plan d'exécution de requêtes plus optimal dans les situations suivantes :

• Lors de l'utilisation de requêtes couvrant plus de 2 tables.
• Lorsque vous disposez d’index contenant un grand nombre de valeurs identiques.
• Lorsque vous utilisez des plages couvrant plus de 10 % du tableau.
• Lorsque vous avez des requêtes complexes dans lesquelles toutes les colonnes utilisées ne sont pas indexées.
• Lorsque des requêtes utilisées impliquent différents moteurs de stockage (par exemple, lorsqu'une requête accède aux tables des moteurs InnoDB et Memory).
• Lors de l'utilisation de FORCE INDEX pour améliorer le plan de requête.
• Lorsque le plan de requête se détériore lors de l'utilisation de "ANALYZE TABLE".
• Lorsque la requête s'étend sur un grand nombre de tables dérivées (grand nombre de SELECT imbriquées).
• Lorsque vous utilisez des expressions ORDER BY ou GROUP BY qui relèvent des index.

Problèmes de compatibilité majeurs dans la branche MariaDB 11 :

• Les droits SUPER ne vous permettent plus d'effectuer des actions pour lesquelles des privilèges définis séparément sont disponibles. Par exemple, pour modifier le format des journaux binaires, vous aurez besoin des droits BINLOG ADMIN.
• Suppression de l'implémentation du tampon de modification dans InnoDB.
• Innodb_flush_method et innodb_file_per_table sont obsolètes.
• La prise en charge des noms Mysql* est obsolète.
• La définition de explicit_defaults_for_timestamp sur 0 est obsolète.
• Les liens symboliques sont inclus dans un package séparé pour la compatibilité avec MySQL.
• La valeur par défaut du paramètre innodb_undo_tablespaces a été modifiée à 3.

Source: opennet.ru