Table des matières de l'article :
Lorsqu'il s'agit de choisir une base de données pour exécuter votre application, MySQL reste l'un des choix les plus populaires. En tant que base de données open source la plus populaire de l'index DB-Engines depuis plus d'une décennie, MySQL fournit une plate-forme fiable. Cependant, le 31 octobre 2023 dernier, la version 5.7 a atteint le statut de fin de vie (EOL).
La fin de vie (EoL) d'un SGBD MySQL fait référence à la fin du support officiel fourni par le fabricant pour une version spécifique de la base de données. Cela signifie qu'aucune mise à jour de sécurité, correctif de bug ou amélioration ne sera publié, rendant le système plus vulnérable aux risques de sécurité et moins compatible avec les nouvelles technologies. Pour les entreprises, EoL signifie qu'elles doivent passer à des versions plus récentes de MySQL pour garantir la sécurité, l'efficacité et la compatibilité de leur base de données. L’échec de la migration peut exposer les données de l’entreprise à des risques de sécurité, à des pertes de données et à des problèmes de performances. De plus, les nouvelles fonctionnalités et optimisations trouvées dans les versions mises à jour de MySQL peuvent être cruciales pour améliorer les performances et l'efficacité globales des systèmes qui utilisent la base de données.
Selon les données de télémétrie de l'outil de gestion de base 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 à jour sous peine de problèmes potentiels.
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 la pile d'applications reçoivent des mises à jour et des modifications régulières, les bases de données nécessitent des compétences spécifiques et une compréhension approfondie pour en tirer le meilleur parti dans des domaines tels que les requêtes, les index et les performances. Une mise à jour complète comme celle-ci peut inspirer des sentiments d’appréhension, mais planifier vos prochaines étapes est essentiel avant votre date EOL.
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 inclut de nombreuses nouvelles commandes qui peuvent améliorer considérablement votre productivité. Un exemple est EXPLAIN ANALYZE, qui peut vous aider à affiner les requêtes. EXPLAIN fournit une estimation du comportement de votre requête, basée sur l'analyse du serveur. Cependant, il ne s’agit que d’une estimation et peut être incorrecte. L'utilisation de ANALYZE avec EXPLAIN exécute la requête, afin que vous puissiez avoir une vue plus précise de la façon dont cette requête se comporte dans la réalité. Il est ainsi beaucoup plus facile de trouver des améliorations potentielles dans cette requête, plutôt que de deviner. De plus, INVISIBLE INDEX vous aide à tester l'efficacité d'un index sans risquer une reconstruction pouvant entraîner de graves problèmes.
En plus de ces changements de syntaxe et de commandes, MySQL 8.0 peut désormais prendre en charge davantage de caractères internationaux car le jeu de caractères par défaut a été mis à jour vers UTF8MB4, qui prend en charge Unicode version 9.0. Ceci est particulièrement utile pour les entreprises ayant des activités à l’échelle mondiale.
Quitter le cache de requêtes MySQL
MySQL Query Cache était autrefois un élément clé pour maximiser les performances des bases de données. Conçue à une époque où les systèmes informatiques étaient basés sur des architectures monocœur et monoserveur, cette fonctionnalité a été optimisée pour de tels environnements, où elle était capable de fournir des résultats rapides et efficaces. Le cache de requêtes fonctionnait en stockant les résultats de requêtes fréquentes, permettant à la base de données de récupérer ces données rapidement, sans avoir besoin de recalculer la même requête à chaque fois.
Cependant, l’évolution technologique a apporté des changements importants dans l’architecture des systèmes informatiques. Avec l’émergence et la popularité des processeurs multicœurs et des architectures multithread, le paysage technologique a subi une transformation radicale. Ces changements ont introduit de nouveaux défis dans la gestion du cache de requêtes MySQL. La nécessité de synchroniser le cache sur plusieurs cœurs et de gérer les accès simultanés à partir de différents threads a considérablement compliqué sa mise en œuvre. Cette complexité croissante a entraîné une augmentation des problèmes de synchronisation et de gestion du cache, entraînant un ralentissement des opérations des bases de données plutôt qu'une accélération.
Face à ces obstacles, Les développeurs MySQL ont pris la décision de rendre obsolète le cache de requêtes dans la version 5.7, puis de l'éliminer complètement dans la version 8. Ce choix a également été influencé par le fait que MySQL 5.7 arrive en fin de vie en octobre 2023, ce qui signifie que les versions ultérieures de MySQL n'incluront plus cette fonctionnalité. Bien que le cache de requêtes ait été supprimé, son concept reste précieux, en particulier dans les scénarios où les requêtes de lecture dominent les opérations d'écriture. Dans de tels contextes, la possibilité de stocker et de récupérer rapidement les résultats des requêtes peut toujours offrir des avantages significatifs en termes d’efficacité et de performances.
L'élimination du cache de requêtes dans MySQL 8 représente un changement substantiel, avec des implications potentiellement critiques, notamment pour les sites Web à fort volume de lecture, comme les blogs WordPress ou les plateformes similaires. Ces sites s'appuient souvent sur des opérations de lecture rapides pour offrir une expérience utilisateur fluide et réactive. Le cache de requêtes, dans ces contextes, a joué un rôle essentiel en réduisant les temps de réponse des bases de données, en stockant les résultats des requêtes les plus fréquentes et en réduisant ainsi la charge sur la base de données elle-même.
La suppression de cette fonctionnalité dans MySQL 8 peut donc entraîner des problèmes de performances importants pour ces sites. Sans Query Cache, chaque requête nécessitera un traitement complet des requêtes de base de données, ce qui augmentera potentiellement les temps de réponse et la charge du serveur. Ce scénario pose un défi majeur aux administrateurs système et aux développeurs de sites Web, qui doivent évaluer soigneusement les avantages et les risques associés à la mise à niveau 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 est représentée par la migration vers MariaDB. Contrairement à MySQL et Percona Server, MariaDB a choisi de maintenir le Query Cache, préservant ainsi ses avantages (et inconvénients) dans des contextes où cette fonctionnalité est particulièrement utile. Ce choix fait de MariaDB une option attractive pour les sites qui s'appuient fortement sur les opérations de lecture et souhaitent préserver les performances offertes par le Query Cache.
Cependant, choisir MariaDB pour conserver les avantages du Query Cache implique aussi d’accepter un compromis en termes de performances globales du système de gestion de base de données (SGBD). Il est important de souligner que, selon les évaluations actuelles, MySQL 8 présente des performances nettement supérieures à celles de MariaDB, une différence à ne pas négliger lors du choix du SGBD.
Les estimations indiquent que les performances de MySQL 8 peuvent être environ le double de celles de MariaDB. Cette différence est attribuable à divers facteurs, notamment des optimisations plus avancées dans MySQL 8, des améliorations dans l'utilisation du matériel moderne, tel que les processeurs multicœurs, et la mise en œuvre de nouvelles fonctionnalités qui augmentent 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'utilité util.checkForServerUpgrade() de MySQL Shell peut vous aider. Il exécute 21 tests différents pour vérifier les problèmes potentiels pouvant affecter votre migration. Les vérifications incluent la recherche de tables dont les noms sont en conflit avec les nouveaux mots-clés réservés et de toutes les variables système qui ont été supprimées ou modifiées par 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. En plus de ces problèmes potentiels, cet utilitaire recherche d'autres problèmes tels que les tables partitionnées utilisant des moteurs de partitionnement non natifs, les références circulaires dans les chemins des fichiers de données des espaces de table et toute utilisation de fonctions supprimées dans MySQL 8.0.
Une fois que vous avez exécuté cet utilitaire et découvert la quantité de travail impliquée dans cette étape, vous avez maintenant le choix. Devriez-vous effectuer cette migration directe de la version 5.7 vers la version 8.0, ou devriez-vous explorer d’autres options ? Si vous devez consacrer un travail important à la préparation de votre application et de votre base de données pour la mise à niveau, devriez-vous plutôt consacrer cet effort à migrer vers une autre plate-forme ou base de données ? De même, vous pourriez décider d’envisager une manière différente de gérer votre infrastructure à l’avenir – par exemple, votre application pourrait actuellement être hébergée sur site, mais vous pourriez plutôt déplacer ces serveurs vers le cloud ou un service hébergé afin de ne pas le faire. Vous n'aurez plus à vous soucier de la gestion de l'infrastructure à l'avenir ?
Chacune de ces options présentera des avantages et des inconvénients potentiels, il est donc important de les évaluer dans leur contexte. Par exemple, les services basés sur le cloud peuvent rendre le fonctionnement beaucoup plus facile, mais vous devez également dépenser davantage en coûts d'exploitation de ces services. De plus, vous devez vérifier le processus d’entrée et de sortie des données de tout service cloud que vous utilisez. Cela permet d’éviter des coûts importants de sortie de données si jamais vous devez modifier votre approche. Enfin, vous devez également vérifier si le service que vous utilisez est open source ou non. Bien que de nombreux fournisseurs prétendent être « compatibles » avec les options de bases de données open source comme MySQL, ils peuvent proposer des modules complémentaires spécifiques à leur service ou leur version.
