{"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\/de\/blog\/novosti-interneta\/vypusk-subd-mysql-9-1-0","title":{"rendered":"Ver\u00f6ffentlichung von MySQL 9.1.0.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Unternehmen Oracle hat einen neuen Zweig der Datenbank MySQL 9.1.0 ins Leben gerufen. Die Builds des MySQL Community Server 9.1.0 sind f\u00fcr alle g\u00e4ngigen Linux-Distributionen, FreeBSD, macOS und Windows vorbereitet. Im Rahmen des letzten Jahr eingef\u00fchrten neuen Modells zur Ver\u00f6ffentlichung von Versionen wird MySQL 9.1 den «Innovation»-Zweigen zugeordnet, zu denen auch die n\u00e4chste bedeutende Version MySQL 9.2 geh\u00f6ren wird. Innovation-Zweige sind f\u00fcr diejenigen empfohlen, die fr\u00fcheren Zugang zu neuen Funktionen w\u00fcnschen, werden alle 3 Monate ver\u00f6ffentlicht und nur bis zur Ver\u00f6ffentlichung der n\u00e4chsten bedeutenden Version unterst\u00fctzt (zum Beispiel wird die Unterst\u00fctzung des Zweigs 9.0 nach dem Erscheinen des Zweigs 9.1 eingestellt). F\u00fcr den Sommer n\u00e4chsten Jahres ist die Erstellung eines LTS-Releases geplant, das f\u00fcr Implementierungen empfohlen wird, die Vorhersehbarkeit und langfristige Beibehaltung unver\u00e4nderter Verhaltensweisen erfordern. Nach dem LTS-Zweig wird ein neuer Innovation-Zweig — MySQL 10.0 — gebildet. <\/p>\n
Haupt\u00e4nderungen in MySQL 9.1: <\/p>\n
\n
In die Operation «CREATE VIEW» wurde die Unterst\u00fctzung des Ausdrucks «IF NOT EXISTS» aufgenommen, der es erm\u00f6glicht, die Erstellung einer Ansicht nur dann zu organisieren, wenn eine Ansicht mit dem angegebenen Namen noch nicht existiert, und die R\u00fcckgabe eines Fehlers zu vermeiden, falls die Ansicht bereits erstellt wurde.\n
Der Trigger-Ladevorgang wurde bei Operationen, die nur Lesezugriffe betreffen, gestoppt. Zuvor wurden Trigger bei jedem Zugriff auf die Tabelle geladen, was zu hohem Speicherverbrauch und CPU-Last f\u00fchrte, wenn die Trigger nicht verwendet wurden (z. B. bei der Ausf\u00fchrung von SELECT-Anfragen). In MySQL 9.1 ist die Verarbeitung und der Ladevorgang von Triggern in zwei Phasen unterteilt: das Lesen von Metadaten \u00fcber den Trigger und die Analyse + Ausf\u00fchrung des Triggers. Die Daten, die in der ersten Phase erhalten werden, werden einmal gespeichert und dann von verschiedenen Instanzen des Triggers gemeinsam genutzt. Die Analyse und Ausf\u00fchrung des Triggers erfolgt nur f\u00fcr Ausdr\u00fccke, die zu Daten\u00e4nderungen f\u00fchren. Dar\u00fcber hinaus wurde der \u00dcbergang zur dynamischen Speicherzuweisung nach Bedarf vollzogen, um den Speicherverbrauch zu reduzieren, anstelle von statischer Pufferzuweisung zur Fehlerbehandlung in Triggern.\n
Die Ausgabe der Operation «EXPLAIN» wurde erweitert, um Informationen \u00fcber die Nutzung von Multi-Range-Lesevorg\u00e4ngen und die Anwendung der Semijoin-Strategie anzuzeigen, bei der bei JOIN-Operationen nur Zeilen aus einer Tabelle verarbeitet werden.\n
Die atomare Ausf\u00fchrung der Operationen «CREATE DATABASE» und «DROP DATABASE» wurde sichergestellt, um vor Ausf\u00e4llen bei einem unerwarteten Programmabschluss oder Fehlern auf Dateisystemebene w\u00e4hrend der Ausf\u00fchrung dieser Operationen zu sch\u00fctzen. Beispielsweise konnte bei einem unerwarteten Programmabschluss von «CREATE DATABASE» zuvor eine unvollst\u00e4ndige, nicht funktionierende Struktur des Datenbankspeichers entstehen, deren Bereinigung manuelles Eingreifen erforderte.\n
In den in JavaScript geschriebenen gespeicherten Prozeduren wird der Typ VECTOR unterst\u00fctzt. Daten mit diesem Typ k\u00f6nnen nun in Eingabe- und R\u00fcckgabewerten \u00fcbergeben werden.\n
Es wurde die M\u00f6glichkeit hinzugef\u00fcgt, sich beim Anschluss an das DBMS mittels des OpenID Connect-Protokolls zu authentifizieren.\n
Es wurden 27 Sicherheitsanf\u00e4lligkeiten behoben, wobei die schwerwiegendste (CVE-2024-5535) mit einem kritischen Gef\u00e4hrdungsgrad (9,1 von 10) bewertet wurde. Diese Sicherheitsanf\u00e4lligkeit kann remote ohne Authentifizierung ausgenutzt werden. Das Problem wird durch das Lesen von Daten aus dem nicht zugewiesenen Speicherbereich in der OpenSSL-Bibliothek verursacht und f\u00fchrt zu einem unerwarteten Abbruch oder zu einer Speicherleckage in der Antwort nach der Verbindung mit dem Server durch<\/a> unter falschen Protokollparametern. <\/ul>\n