{"id":120215,"date":"2024-10-17T19:09:08","date_gmt":"2024-10-17T17:09:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-subd-mysql-9-1-0"},"modified":"2024-10-17T19:09:08","modified_gmt":"2024-10-17T17:09:08","slug":"vypusk-subd-mysql-9-1-0","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/vypusk-subd-mysql-9-1-0","title":{"rendered":"Publication de la base de donn\u00e9es MySQL 9.1.0","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
La soci\u00e9t\u00e9 Oracle a cr\u00e9\u00e9 une nouvelle branche du SGBD MySQL 9.1.0. Les compilations de MySQL Community Server 9.1.0 sont pr\u00e9par\u00e9es pour toutes les principales distributions de Linux, FreeBSD, macOS et Windows. Dans le cadre du nouveau mod\u00e8le de publication des versions mis en place l'ann\u00e9e derni\u00e8re, MySQL 9.1 est class\u00e9 dans les branches \u00ab Innovation \u00bb, auxquelles sera \u00e9galement ajout\u00e9 la prochaine version majeure de MySQL 9.2. Les branches Innovation sont recommand\u00e9es pour ceux qui souhaitent acc\u00e9der plus t\u00f4t \u00e0 de nouvelles fonctionnalit\u00e9s, elles sont publi\u00e9es tous les 3 mois et ne sont prises en charge que jusqu'\u00e0 la publication de la prochaine version majeure (par exemple, apr\u00e8s la sortie de la branche 9.1, le support de la branche 9.0 est arr\u00eat\u00e9). L'\u00e9t\u00e9 prochain, il est pr\u00e9vu de cr\u00e9er une version LTS, recommand\u00e9e pour les d\u00e9ploiements n\u00e9cessitant pr\u00e9visibilit\u00e9 et un comportement stable \u00e0 long terme. Apr\u00e8s la branche LTS, une nouvelle branche Innovation sera form\u00e9e \u2014 MySQL 10.0. <\/p>\n
Principales modifications dans MySQL 9.1 : <\/p>\n
\n
L'op\u00e9ration \u00ab CREATE VIEW \u00bb a \u00e9t\u00e9 enrichie d'un support pour l'expression \u00ab IF NOT EXISTS \u00bb, permettant de cr\u00e9er une vue uniquement si une vue avec le nom sp\u00e9cifi\u00e9 n'existe pas d\u00e9j\u00e0, \u00e9vitant ainsi de renvoyer une erreur si la vue a d\u00e9j\u00e0 \u00e9t\u00e9 cr\u00e9\u00e9e.\n
Le chargement des d\u00e9clencheurs a \u00e9t\u00e9 interrompu lors de l'ex\u00e9cution d'op\u00e9rations se limitant \u00e0 la lecture. Auparavant, les d\u00e9clencheurs \u00e9taient charg\u00e9s \u00e0 chaque acc\u00e8s \u00e0 la table, ce qui entra\u00eenait une consommation de m\u00e9moire et une charge sur le CPU dans des situations o\u00f9 les d\u00e9clencheurs n'\u00e9taient pas utilis\u00e9s (comme lors d'ex\u00e9cutions de requ\u00eates SELECT). Dans MySQL 9.1, le traitement et le chargement des d\u00e9clencheurs sont s\u00e9par\u00e9s en deux \u00e9tapes : la lecture des m\u00e9tadonn\u00e9es du d\u00e9clencheur et l'analyse + l'ex\u00e9cution du d\u00e9clencheur. Les donn\u00e9es obtenues \u00e0 la premi\u00e8re \u00e9tape sont conserv\u00e9es une fois et ensuite partag\u00e9es dans diff\u00e9rentes instances du d\u00e9clencheur. L'analyse et l'ex\u00e9cution du d\u00e9clencheur ne sont effectu\u00e9es que pour les expressions qui entra\u00eenent une modification des donn\u00e9es. De plus, pour r\u00e9duire la consommation de m\u00e9moire, plut\u00f4t que d'allouer statiquement des tampons pour la gestion des erreurs dans les d\u00e9clencheurs, un passage \u00e0 une allocation dynamique de m\u00e9moire selon les besoins a \u00e9t\u00e9 r\u00e9alis\u00e9.\n
La sortie de l'op\u00e9ration \u00ab EXPLAIN \u00bb a \u00e9t\u00e9 \u00e9tendue, affichant d\u00e9sormais des informations sur l'utilisation de la lecture multi-plage (multi-range) et l'application de la strat\u00e9gie de semi-jointure (semijoin), dans laquelle lors des op\u00e9rations JOIN, seules les lignes d'une seule table sont trait\u00e9es.\n
L'ex\u00e9cution atomique des op\u00e9rations \u00ab CREATE DATABASE \u00bb et \u00ab DROP DATABASE \u00bb a \u00e9t\u00e9 assur\u00e9e pour se prot\u00e9ger contre les pannes en cas d'arr\u00eat brutal ou d'erreurs au niveau du syst\u00e8me de fichiers pendant l'ex\u00e9cution de ces op\u00e9rations. Par exemple, auparavant, lors d'un arr\u00eat brutal de \u00ab CREATE DATABASE \u00bb, une structure de stockage de base de donn\u00e9es incompl\u00e8te et non fonctionnelle pouvait \u00eatre cr\u00e9\u00e9e, n\u00e9cessitant une intervention manuelle pour la nettoyer.\n
Les proc\u00e9dures stock\u00e9es \u00e9crites en JavaScript prennent d\u00e9sormais en charge le type VECTOR. Les donn\u00e9es de ce type peuvent maintenant \u00eatre transmises dans les param\u00e8tres d'entr\u00e9e et de sortie.\n
Ajout de la possibilit\u00e9 d'authentification lors de la connexion \u00e0 la SGBD en utilisant le protocole OpenID Connect.\n
27 vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 corrig\u00e9es, dont la plus s\u00e9rieuse (CVE-2024-5535) class\u00e9e comme critique (9.1 sur 10). Cette vuln\u00e9rabilit\u00e9 peut \u00eatre exploit\u00e9e \u00e0 distance sans authentification. Elle est caus\u00e9e par la lecture de donn\u00e9es en dehors de la zone de tampon allou\u00e9e dans la biblioth\u00e8que OpenSSL, entra\u00eenant un plantage ou une fuite du contenu de la m\u00e9moire dans la r\u00e9ponse apr\u00e8s connexion avec serveur<\/a> en sp\u00e9cifiant des param\u00e8tres de protocole incorrects. <\/ul>\n