Table des matières de l'article :
Lorsqu'il s'agit de choisir une base de données pour exécuter une application, MySQL demeure l'une des solutions les plus populaires. Base de données open source la plus utilisée dans l'index DB-Engines depuis plus de dix ans, MySQL offre une plateforme fiable. Toutefois, le 31 octobre 2023, la version 5.7 a atteint sa fin de vie (EOL).
La fin de vie (EoL) d'un SGBD MySQL correspond à l'arrêt du support officiel fourni par l'éditeur pour une version spécifique de la base de données. Cela signifie que les mises à jour de sécurité, les correctifs et les améliorations ne seront plus publiés, rendant le système plus vulnérable aux risques de sécurité et moins compatible avec les nouvelles technologies. Pour les entreprises, la fin de vie implique la migration vers des versions plus récentes de MySQL afin de garantir la sécurité, l'efficacité et la compatibilité de leur base de données. Ne pas migrer peut exposer les données de l'entreprise à des risques de sécurité, à des pertes de données et à des problèmes de performance. De plus, les nouvelles fonctionnalités et les optimisations des versions mises à jour de MySQL peuvent être cruciales pour améliorer les performances et l'efficacité globales des systèmes utilisant la base de données.
D'après les données de télémétrie de l'outil de gestion de bases de données open source PMM, plus de la moitié des utilisateurs de MySQL utilisent actuellement la version 5.7. Cela signifie que de nombreuses instances devront être mises à niveau sous peine de rencontrer des problèmes.
Cependant, de nombreux développeurs hésitent à modifier leurs installations de bases de données une fois qu'elles fonctionnent correctement. Alors que d'autres éléments de l'architecture applicative font l'objet de mises à jour régulières, les bases de données exigent des compétences spécifiques et une compréhension approfondie de leur fonctionnement optimal, notamment en matière de requêtes, d'index et de performances. Une mise à niveau complète de ce type peut susciter des appréhensions, mais il est essentiel de planifier les prochaines étapes avant la date de fin de vie.
Que signifie cette mise à jour ?
Tout d’abord, il est important de regarder ce que propose la migration pour améliorer l’exécution de votre application et augmenter votre productivité. Pour commencer, MySQL 8.0 prend en charge un certain nombre de mises à jour de SQL (Structured Query Language) qui facilitent l'écriture et la prise en charge des requêtes. Les requêtes efficaces sont au cœur de la façon dont vous utilisez les données dans votre application et votre entreprise, donc tout ce qui améliore cela devrait avoir un impact direct sur votre travail.
Les sous-requêtes en sont un bon exemple. Leur création peut être difficile si vous ne travaillez pas avec SQL tous les jours, donc tirer parti d'options telles que les jointures dérivées latérales et les expressions de table communes (CTE) peut vous aider. Les CTE aident à composer et à gérer des requêtes complexes en les divisant en unités plus petites que vous pouvez réutiliser au fil du temps. En gardant les choses simples et lisibles, cela permet de créer les requêtes dont vous avez besoin dans votre application. Il existe également une nouvelle clause d'intersection pour vous aider avec les ensembles, vous aidant à trouver des points de données communs dans deux ensembles de données ou plus sans avoir à écrire des requêtes très complexes.
MySQL 8.0 intègre de nombreuses nouvelles commandes qui peuvent considérablement améliorer votre productivité. Par exemple, EXPLAIN ANALYZE vous aide à optimiser vos requêtes. EXPLAIN fournit une estimation du comportement attendu de votre requête, basée sur l'analyse du serveur. Cependant, il ne s'agit que d'une estimation et elle peut être erronée. L'utilisation conjointe d'ANALYZE et d'EXPLAIN permet d'exécuter la requête, offrant ainsi une vision plus précise de ses performances réelles. Il devient alors beaucoup plus facile d'identifier les axes d'amélioration potentiels, plutôt que de procéder par tâtonnements. De plus, INVISIBLE INDEX vous permet de tester l'efficacité d'un index sans risquer une reconstruction susceptible d'entraîner de graves problèmes.
Outre ces modifications de syntaxe et de commandes, MySQL 8.0 prend désormais en charge davantage de caractères internationaux grâce à la mise à jour du jeu de caractères par défaut vers UTF-8MB4, assurant ainsi la compatibilité avec Unicode version 9.0. Ceci est particulièrement utile pour les entreprises opérant à l'échelle mondiale.
Quitter le cache de requêtes MySQL
Le cache de requêtes de MySQL était autrefois un élément clé pour optimiser les performances des bases de données. Conçue à une époque où les systèmes informatiques reposaient sur des architectures monocœur et monoserveur, cette fonctionnalité était optimisée pour ces environnements, où elle pouvait fournir des résultats rapides et efficaces. Le cache de requêtes fonctionnait en stockant les résultats des requêtes fréquemment utilisées, permettant ainsi à la base de données de récupérer rapidement ces données, sans avoir à recalculer la même requête à chaque fois.
Cependant, l'évolution technologique a profondément modifié l'architecture des systèmes informatiques. Avec l'émergence et la popularisation des processeurs multicœurs et des architectures multithread, le paysage technologique a connu une transformation radicale. Ces changements ont engendré de nouveaux défis pour la gestion du cache des requêtes MySQL. La nécessité de synchroniser le cache sur plusieurs cœurs et de gérer les accès concurrents depuis différents threads a considérablement complexifié sa mise en œuvre. Cette complexité croissante a entraîné une augmentation des problèmes de synchronisation et de gestion du cache, ce qui se traduit par des opérations de base de données plus lentes.
Face à ces obstacles, les développeurs de MySQL ont décidé de rendre obsolète le cache de requêtes dans la version 5.7, puis de le supprimer complètement dans la version 8. Cette décision a également été influencée par la fin de vie de MySQL 5.7 en octobre 2023, ce qui impliquait que les versions ultérieures de MySQL ne prendraient plus en charge cette fonctionnalité. Bien que le cache de requêtes ait été supprimé, son principe reste pertinent, notamment lorsque les requêtes de lecture sont plus fréquentes que les opérations d'écriture. Dans ce contexte, la possibilité de stocker et de récupérer rapidement les résultats de requêtes peut encore apporter des gains significatifs en termes d'efficacité et de performances.
La suppression du cache de requêtes dans MySQL 8 représente un changement majeur, aux conséquences potentiellement critiques , notamment pour les sites web à fort trafic, tels que les blogs WordPress ou les plateformes similaires. Ces sites dépendent souvent de la rapidité des opérations de lecture pour offrir une expérience utilisateur fluide et réactive. Dans ce contexte, le cache de requêtes jouait un rôle essentiel dans la réduction des temps de réponse de la base de données en stockant les résultats des requêtes fréquemment utilisées et en allégeant ainsi la charge sur la base de données elle-même.
La suppression de cette fonctionnalité dans MySQL 8 pourrait donc entraîner des problèmes de performance importants pour ces sites. Sans le cache de requêtes, chaque requête nécessitera le traitement complet de la requête de base de données, ce qui risque d'augmenter les temps de réponse et la charge du serveur. Ce scénario représente un défi majeur pour les administrateurs système et les développeurs web, qui doivent soigneusement évaluer les avantages et les risques liés à la migration vers MySQL 8.
Dans certains cas, il peut être conseillé de conserver MySQL 5.7 pour conserver les avantages du cache de requêtes, même si cette version atteint la fin de vie. Cependant, ce choix peut s’accompagner de risques de sécurité et d’un manque de support, ce qui en fait une solution temporaire et loin d’être idéale à long terme.
Une alternative intéressante consiste à migrer vers MariaDB. Contrairement à MySQL et Percona Server, MariaDB a choisi de conserver le cache de requêtes, préservant ainsi ses avantages (et ses inconvénients) dans les contextes où cette fonctionnalité est particulièrement utile. Ce choix fait de MariaDB une option attrayante pour les sites qui dépendent fortement des opérations de lecture et souhaitent préserver les performances offertes par le cache de requêtes.
Cependant, choisir MariaDB pour bénéficier du cache de requêtes implique un compromis en termes de performances globales du système de gestion de base de données (SGBD). Il est important de noter que, selon les mesures actuelles, MySQL 8 est nettement plus performant que MariaDB ; une différence à ne pas négliger lors du choix d'un SGBD.
Les estimations indiquent que les performances de MySQL 8 pourraient être environ deux fois supérieures à celles de MariaDB. Cette différence s'explique par plusieurs facteurs, notamment des optimisations plus poussées dans MySQL 8, une meilleure utilisation du matériel moderne, comme les processeurs multicœurs, et la mise en œuvre de nouvelles fonctionnalités qui améliorent l'efficacité globale du système.
Par exemple, MySQL 8 a introduit des améliorations dans l'optimisation des requêtes, la gestion de la mémoire et les opérations d'E/S, contribuant ainsi à une augmentation spectaculaire des performances. De plus, MySQL 8 prend en charge des fonctionnalités avancées telles que le DDL atomique (Data Definition Language), qui améliore la gestion et la sécurité des opérations de définition de données.
Planifier la mise à niveau
La migration de MySQL 5.7 vers 8.0 est une démarche simple, mais certains changements spécifiques et importants peuvent affecter vos applications. La vérification préalable de votre application et de votre base de données indiquera si ce processus sera simple ou si vous devrez apporter des modifications plus complexes dans le cadre du processus de migration.
L' utilitaire MySQL Shell ` util.checkForServerUpgrade()` peut vous aider. Il exécute 21 tests différents pour détecter les problèmes potentiels susceptibles d'affecter votre migration. Ces vérifications incluent la recherche de noms de tables en conflit avec les nouveaux mots-clés réservés et la présence de variables système supprimées ou modifiées (avec de nouvelles valeurs par défaut) dans MySQL 8.0. La liste complète des variables ajoutées, obsolètes et supprimées est disponible ici. Outre ces problèmes potentiels, cet utilitaire vérifie également d'autres points, tels que les tables partitionnées utilisant des moteurs de partitionnement non natifs, les références circulaires dans les chemins d'accès aux fichiers de données des espaces de tables et l'utilisation de fonctions supprimées dans MySQL 8.0.
Une fois cet outil exécuté et l'ampleur de la migration évaluée, vous avez le choix. Faut-il migrer directement de la version 5.7 à la version 8.0, ou explorer d'autres options ? Si la préparation de votre application et de votre base de données pour la mise à niveau exige un travail considérable, ne vaudrait-il pas mieux investir cet effort dans une migration vers une autre plateforme ou base de données ? De même, vous pourriez envisager une autre méthode de gestion de votre infrastructure. Par exemple, si votre application est actuellement hébergée sur site, pourriez-vous migrer ces serveurs vers le cloud ou un service hébergé afin de vous affranchir de la gestion de l'infrastructure à l'avenir ?
Chacune de ces options présente des avantages et des inconvénients potentiels ; il est donc important de les évaluer dans leur contexte. Par exemple, les services cloud facilitent grandement la mise en œuvre, mais leur gestion engendre des coûts plus élevés. De plus, il est essentiel d'examiner le processus d'ingestion et d'extraction des données de tout service cloud envisagé. Cela permet d'éviter des coûts importants liés à une interruption de service si vous devez modifier votre approche. Enfin, il convient également de vérifier si le service est open source. Bien que de nombreux fournisseurs se disent « compatibles » avec les bases de données open source comme MySQL, ils peuvent proposer des modules complémentaires spécifiques à leur service ou à leur version.
