{"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\/news\/vypusk-subd-mysql-9-1-0","title":{"rendered":"Version der Datenbank MySQL 9.1.0","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Unternehmen Oracle hat einen neuen Zweig der DBMS MySQL 9.1.0 gebildet. Die Builds von MySQL Community Server 9.1.0 sind f\u00fcr alle g\u00e4ngigen Linux-Distributionen, FreeBSD, macOS und Windows vorbereitet. Im Rahmen des im vergangenen Jahr eingef\u00fchrten neuen Modells zur Erstellung von Releases wird MySQL 9.1 den \u201eInnovation\u201c-Zweigen zugeordnet, zu denen auch die n\u00e4chste signifikante Version MySQL 9.2 geh\u00f6ren wird. Innovation-Zweige werden f\u00fcr diejenigen empfohlen, die fr\u00fchzeitig Zugang zu neuen Funktionen erhalten m\u00f6chten, erscheinen alle 3 Monate und werden nur bis zur Ver\u00f6ffentlichung des n\u00e4chsten signifikanten Releases unterst\u00fctzt (beispielsweise wird nach Erscheinen des Zweigs 9.1 die Unterst\u00fctzung des Zweigs 9.0 eingestellt). Im Sommer des n\u00e4chsten Jahres wird ein LTS-Release geplant, das f\u00fcr Implementierungen empfohlen wird, die Vorhersehbarkeit und eine langfristige Beibehaltung unver\u00e4nderter Verhaltensweisen erfordern. Nach dem LTS-Zweig wird ein neuer Innovation-Zweig \u2013 MySQL 10.0 \u2013 gebildet. <\/p>\n
Die wichtigsten \u00c4nderungen in MySQL 9.1: <\/p>\n
\n
In die Operation \u201eCREATE VIEW\u201c wurde die Unterst\u00fctzung des Ausdrucks \u201eIF NOT EXISTS\u201c aufgenommen, der das Erstellen einer Ansicht nur dann erm\u00f6glicht, wenn eine Ansicht mit dem angegebenen Namen noch nicht existiert, und das Zur\u00fcckgeben eines Fehlers vermeidet, wenn die Ansicht bereits erstellt wurde.\n
Die Ladung von Triggern wurde eingestellt, wenn nur Leseoperationen ausgef\u00fchrt werden. Zuvor wurden Trigger bei jedem Zugriff auf die Tabelle geladen, was zu einem hohen Speicherverbrauch und einer Belastung der CPU f\u00fchrte, wenn die Trigger nicht verwendet wurden (z.B. bei der Ausf\u00fchrung von SELECT-Abfragen). In MySQL 9.1 wurde die Verarbeitung und das Laden von Triggern in zwei Phasen unterteilt: Lesen der Metadaten \u00fcber den Trigger und Parsen+Ausf\u00fchren des Triggers. Daten, die in der ersten Phase gesammelt werden, werden einmal gespeichert und dann gemeinsam in verschiedenen Instanzen des Triggers verwendet. Das Parsen und Ausf\u00fchren des Triggers erfolgt nur f\u00fcr Ausdr\u00fccke, die zu Daten\u00e4nderungen f\u00fchren. Dar\u00fcber hinaus wurde der \u00dcbergang zu dynamischer Speicherzuweisung nach Bedarf vorgenommen, um den Speicherverbrauch zu reduzieren, anstelle von statischer Zuweisung von Puffern zur Bearbeitung von Fehlern in den Triggern.\n
Die Ausgabe der Operation \u201eEXPLAIN\u201c wurde erweitert, die nun Informationen \u00fcber die Verwendung von Multi-Range-Scans und die Anwendung der Semi-Join-Strategie anzeigt, bei der bei JOIN-Operationen nur Zeilen aus einer Tabelle verarbeitet werden.\n
Die atomare Ausf\u00fchrung der Operationen \u201eCREATE DATABASE\u201c und \u201eDROP DATABASE\u201c wurde sichergestellt, um vor Ausf\u00e4llen aufgrund von unerwarteten Beendigungen oder Fehlern auf Dateisystemebene w\u00e4hrend der Durchf\u00fchrung dieser Operationen zu sch\u00fctzen. Beispielsweise konnte zuvor bei einem unerwarteten Ende von \u201eCREATE DATABASE\u201c eine unvollst\u00e4ndige, nicht funktionierende Datenbankstruktur erstellt werden, deren Bereinigung manuelles Eingreifen erforderte.\n
In den in JavaScript geschriebenen Stored Procedures wird die Unterst\u00fctzung des Typs VECTOR gew\u00e4hrleistet. Daten mit diesem Typ k\u00f6nnen jetzt in Eingangs- und R\u00fcckgabewerten \u00fcbergeben werden.\n
Die M\u00f6glichkeit zur Authentifizierung bei der Verbindung zur DBMS unter Verwendung des OpenID Connect-Protokolls wurde hinzugef\u00fcgt.\n
27 Schwachstellen wurden behoben, von denen die schwerwiegendste (CVE-2024-5535) als kritisch (9,1 von 10) eingestuft wurde. Diese Schwachstelle kann aus der Ferne ohne Authentifizierung ausgenutzt werden. Das Problem wird durch das Lesen von Daten aus dem Bereich au\u00dferhalb des zugewiesenen Puffers in der OpenSSL-Bibliothek verursacht und f\u00fchrt zu einem Absturz oder zu einem Speicherleck im Antwortinhalt nach der Verbindung mit Server<\/a> unter Angabe ung\u00fcltiger Protokollparameter. <\/ul>\n