Da das meiste, wenn nicht das ganze Jahr 2018 hinter uns liegt (je nachdem, wann Sie diesen Beitrag lesen), besteht kein Zweifel daran, dass es ein fantastisches Jahr für Open-Source-SQL-Datenbanken war.
PostgreSQL 11 und MySQL 8 wurden beide veröffentlicht und boten beiden Communities viel Gesprächsstoff '. Um ehrlich zu sein, haben beide Anbieter viele bedeutende Änderungen und Ergänzungen in ihren jeweiligen Versionen eingeführt und verdienen ihr Lob und ihre Auszeichnungen.
Über Ersteres schreibe ich normalerweise als Gast hier im Blog von Multiplenines (Vielen Dank an eine großartige Organisation!), aber ich interessiere mich auch für Letzteres. Mit vielen Blogposts auf meiner eigenen Website (Link in meinem Bio-Bereich), die hauptsächlich auf MySQL Version 5.7 abzielen, ist es (MySQL) immer in meinen Peripheriegeräten.
Was hat MySQL 8 also, was Version 5.7 nicht hat? Was sind die Verbesserungen? Nun, es gibt viele. Eigentlich zu viele, um sie in nur einem Blogbeitrag zu behandeln.
Ich habe kürzlich in meiner aktuellen Linux-Lern-/Entwicklungsumgebung auf Version 8 aktualisiert, also dachte ich, ich versuche, einige davon aufzuzeigen.
Ich kann Ihnen keine ausführliche Diskussion über Ihren 'Favoriten garantieren ' Neue Eigenschaften). Auf der anderen Seite werde ich diejenigen besuchen, die meine Aufmerksamkeit entweder durch ein persönliches Interesse oder durch die vielen großartigen Blog-Posts erregt haben, die das ganze Jahr über zu Version 8 veröffentlicht wurden.
MySQL wird immer besser ... Tolle Verbesserungen in Version 8!
Rollen
Mit Rollen können DBAs Redundanzen mindern, bei denen viele Benutzer dieselben Berechtigungen oder denselben Satz von Berechtigungen teilen würden.
Rollen sind ein Teil des SQL-Standards.
Nachdem Sie eine bestimmte Rolle mit den gewünschten/erforderlichen Rechten erstellt haben, können Sie Benutzern diese bestimmte Rolle über den GRANT-Befehl zuweisen oder ebenso 'wegnehmen ' mit REVOKE.
Rollen bringen zahlreiche Vorteile mit sich, und um Ihnen das Leben ein bisschen leichter zu machen, gibt es ein paar Tabellen, die Ihnen dabei helfen, den Überblick zu behalten:
-
mysql.role_edges – Hier finden Sie diese Rollen und die ihnen zugewiesenen Benutzer.
mysql> DESC mysql.role_edges; +-------------------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+---------------+------+-----+---------+-------+ | FROM_HOST | char(60) | NO | PRI | | | | FROM_USER | char(32) | NO | PRI | | | | TO_HOST | char(60) | NO | PRI | | | | TO_USER | char(32) | NO | PRI | | | | WITH_ADMIN_OPTION | enum('N','Y') | NO | | N | | +-------------------+---------------+------+-----+---------+-------+ 5 rows in set (0.01 sec) -
mysql.default_roles – Speichert alle Standardrollen und die zugewiesenen Benutzer.
mysql> DESC mysql.default_roles; +-------------------+----------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------------+----------+------+-----+---------+-------+ | HOST | char(60) | NO | PRI | | | | USER | char(32) | NO | PRI | | | | DEFAULT_ROLE_HOST | char(60) | NO | PRI | % | | | DEFAULT_ROLE_USER | char(32) | NO | PRI | | | +-------------------+----------+------+-----+---------+-------+ 4 rows in set (0.00 sec)
Die Kombination beider Tabellen (nicht im Sinne von SQL JOIN) bietet im Wesentlichen einen 'zentralisierten Ort ' wo Sie:alle Ihre implementierten Benutzerrollen-Berechtigungsbeziehungen und -Zuweisungen kennen, überwachen und bewerten können.
Das wahrscheinlich einfachste Beispielszenario für die Rollennutzung wäre:
Sie haben mehrere Benutzer, die 'Nur-Lese-Zugriff benötigen ' für eine bestimmte Tabelle und erfordert daher mindestens das SELECT-Privileg. Anstatt es jedem Benutzer einzeln zu erteilen (SELECT), können Sie eine Rolle mit diesem Recht einrichten (erstellen) und diese Rolle dann diesen Benutzern zuweisen.
Aber Rollen haben einen kleinen „Haken '. Nach der Erstellung und Zuweisung an einen Benutzer muss der empfangende Benutzer während der Authentifizierung bei der Anmeldung über einen aktiven Standardrollensatz verfügen.
Beim Thema Rollen und Benutzer finde ich es wichtig, die in MySQL 8 implementierte Änderung bezüglich der validate_password-Komponente zu erwähnen, die eine Variante des validate_password-Plugins ist, das in Version 5.7 verwendet wird.
Diese Komponente bietet verschiedene unterschiedliche 'Kategorien ' der Passwortprüfung:niedrig, mittel (Standard) und stark. Besuchen Sie die Dokumentation der validate_password-Komponente für einen vollständigen Überblick über die Validierungsspezifikationen der einzelnen Ebenen.
NoSQL-Mischung mit SQL – Der Dokumentenspeicher
Über diese Funktion lerne ich immer noch, trotz eines flüchtigen Interesses an MongoDB Anfang 2016. Bis heute haben sich mein Interesse, mein Studium und mein Lernen ausschließlich auf „SQL“ konzentriert. Mir ist jedoch bewusst (durch viel Lesen im Internet), dass viele von dieser Art der Strukturierung (dokumentorientiert) begeistert sind, die mit „relationalem SQL“ verflochten ist, das jetzt im Dokumentenspeicher von MySQL 8 verfügbar ist.
Nachfolgend sind viele Vorteile aufgeführt, die bei der Verwendung des Dokumentenspeichers verfügbar sind. Seien Sie sicher und erwähnen Sie Ihre Favoriten, die ich vielleicht in den Kommentaren vermisst habe:
- Der JSON-Datentyp wird seit MySQL-Version 5.7.8 unterstützt, Version 8 führte jedoch erhebliche Verbesserungen für die Arbeit mit JSON ein. Neue JSON-spezifische Funktionen zusammen mit 'Shorthand ' Operatoren, die anstelle mehrerer Funktionsaufrufe verwendet werden können - mit gleichen Ergebnissen/Ausgaben.
- Vielleicht ist einer der wichtigsten Vorteile, dass Sie nicht mehr mehrere Datenbanklösungen implementieren und damit arbeiten müssen, da NoSQL, SQL oder eine Kombination aus beiden im Dokumentenspeicher unterstützt werden.
- Eine „DevAPI“ bietet nahtlose Workflow-Funktionen innerhalb eines NoSQL-Datenkontexts (Sammlungen und Dokumente). (Besuchen Sie die offizielle Dokumentation des DevAPI-Benutzerhandbuchs für weitere Informationen).
- Leistungsstarke Befehlszeilensitzungen mit Python, SQL oder Javascript als "Shell"-Sprache.
- ACID-konform.
- Untersuchen und entdecken Sie Ihre Daten schnell, ohne ein Schema zu definieren, wie Sie es in einem relationalen Modell tun würden.
Allgemeine Tabellenausdrücke (CTEs oder die WITH-Klausel)
Was können Sie sonst noch über CTE sagen? Diese Dinge sind ein Game-Changer! Was genau ist ein allgemeiner Tabellenausdruck?
Aus Wikipedia:
"Ein allgemeiner Tabellenausdruck oder CTE (in SQL) ist eine temporäre benannte Ergebnismenge, die von einer einfachen Abfrage abgeleitet und innerhalb des Ausführungsbereichs einer SELECT-, INSERT-, UPDATE- oder DELETE-Anweisung definiert wird."
Ich werde ein einfaches Beispiel geben, das CTEs demonstriert. Ihre volle Leistungsfähigkeit wird in diesem Abschnitt jedoch nicht genutzt, da es viel komplexere Anwendungsbeispiele als diese gibt.
Ich habe eine einfache Namenstabelle mit dieser Beschreibung und diesen Daten:
mysql> DESC name;
+--------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| f_name | varchar(20) | YES | | NULL | |
| l_name | varchar(20) | YES | | NULL | |
+--------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)mysql> SELECT * FROM name;
+--------+------------+
| f_name | l_name |
+--------+------------+
| Jim | Dandy |
| Johhny | Applesauce |
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+------------+
5 rows in set (0.00 sec)Lassen Sie uns herausfinden, wie viele Nachnamen mit „Z“ beginnen:
mysql> SELECT *
-> FROM name
-> WHERE l_name LIKE 'Z%';
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+--------+
3 rows in set (0.00 sec)Ganz einfach.
Mit der WITH-Klausel können Sie jedoch 'zugreifen ' dieselbe Abfrageergebnismenge (die man sich als abgeleitete Tabelle vorstellen kann) und später innerhalb derselben Anweisung - oder 'Scope - darauf verweisen ':
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%')
SELECT * FROM last_Z;
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+--------+
3 rows in set (0.00 sec)Im Grunde weise ich der Abfrage einen Namen zu und setze ihn in Klammern. Wählen Sie dann einfach die Daten aus, die ich möchte, aus dem, was jetzt der last_Z CTE ist.
Der CTE last_Z stellt eine vollständige Ergebnismenge bereit, sodass Sie sie innerhalb derselben Anweisung noch weiter filtern können:
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%')
SELECT f_name, l_name FROM last_Z WHERE l_name LIKE '%a';
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashton | Zerra |
+--------+--------+
1 row in set (0.00 sec)Einige der leistungsstärkeren Funktionen sind 'Verkettung ' mehrere CTEs zusammen und Verweis auf andere CTEs innerhalb von CTEs.
Hier ist ein Beispiel, um Ihnen eine Idee zu geben (wenn auch nicht so sehr nützlich):
WITH last_Z AS (
SELECT *
FROM name
WHERE l_name LIKE 'Z%'),
best_friend AS (
SELECT f_name, l_name
FROM last_Z
WHERE l_name LIKE '%a')
SELECT * from best_friend;
+--------+--------+
| f_name | l_name |
+--------+--------+
| Ashton | Zerra |
+--------+--------+
1 row in set (0.00 sec)In der obigen Abfrage können Sie sehen, wo ich den CTE last_Z vom CTE best_friend durch ein Komma getrennt und diese Abfrage dann in Klammern nach dem Schlüsselwort AS eingefügt habe.
Beachten Sie, dass ich mich dann auf den last_Z-CTE beziehen (und ihn verwenden) kann, um im Wesentlichen den best_friend-CTE zu definieren.
Hier sind einige Gründe, warum CTEs eine so bedeutende Verbesserung in Version 8 darstellen:
- Andere SQL-Anbieter haben CTEs unterstützt (viele seit früheren Versionen innerhalb ihres individuellen Ökosystems) und jetzt hat MySQL 8 die Lücke in diesem Bereich geschlossen.
- Eine standardmäßige SQL-Einbindung.
- In einigen Fällen (sofern zutreffend) sind CTEs eine bessere Option als temporäre Tabellen, Ansichten, abgeleitete Tabellen (oder Inline-Ansichten) und einige Unterabfragen.
- CTEs können einen 'on-the-fly liefern ' Berechnungsergebnisse, die Sie abfragen können.
- Ein CTE kann auf sich selbst verweisen – bekannt als rekursiver CTE (hier nicht gezeigt).
- CTEs können andere CTEs benennen und verwenden
Fensterfunktionen
Analytische Abfragen sind jetzt in MySQL 8 möglich. Da Windows-Funktionen nicht meine Stärke sind, konzentriere ich mich auf eine eingehendere Untersuchung und ein besseres Verständnis von ihnen im Allgemeinen, um voranzukommen. Diese nächsten Beispiele sind nach meinem Verständnis meist elementar. Anregungen, Ratschläge und Best Practices sind von Lesern willkommen.
Ich habe diese Ansicht, die einen fiktiven Pipe-Daten-Ergebnissatz liefert (etwas, was ich einigermaßen verstehe):
mysql> SELECT * FROM pipe_vw;
+---------+-------------+-----------+-------+-------------+------------+----------------+
| pipe_id | pipe_name | joint_num | heat | pipe_length | has_degree | wall_thickness |
+---------+-------------+-----------+-------+-------------+------------+----------------+
| 181 | Joint-278 | 39393A | 9111 | 17.40 | 1 | 0.393 |
| 182 | Joint-8819 | 19393Y | 9011 | 16.60 | 0 | 0.427 |
| 183 | Joint-9844 | 39393V | 8171 | 10.40 | 0 | 0.393 |
| 184 | Joint-2528 | 34493U | 9100 | 11.50 | 1 | 0.427 |
| 185 | Joint-889 | 18393z | 9159 | 13.00 | 0 | 0.893 |
| 186 | Joint-98434 | 19293Q | 8174 | 9.13 | 0 | 0.893 |
| 187 | Joint-78344 | 17QTT | 179 | 44.40 | 1 | 0.893 |
| 188 | Joint-171C | 34493U | 17122 | 9.45 | 1 | 0.893 |
| 189 | Joint-68444 | 17297Q | 6114 | 11.34 | 0 | 0.893 |
| 190 | Joint-4841R | 19395Q | 5144 | 25.55 | 0 | 0.115 |
| 191 | Joint-1224C | 34493U | 8575B | 15.22 | 1 | 0.893 |
| 192 | Joint-2138 | 34493C | 91 | 13.55 | 1 | 0.893 |
| 193 | Joint-122B | 34493U | 9100B | 7.78 | 1 | 0.893 |
+---------+-------------+-----------+-------+-------------+------------+----------------+
13 rows in set (0.00 sec)Stellen Sie sich vor, ich brauche die Rohranlagendatensätze, die in einer Art Reihenrangfolge dargestellt werden, abhängig von der Länge jedes einzelnen Rohres. (Beispiel:Die längste Länge ist mit Position 1 gekennzeichnet, die zweitlängste Länge ist mit Position 2 gekennzeichnet usw.)
Basierend auf der Beschreibung der Fensterfunktion RANK() in der Dokumentation:
"Gibt den Rang der aktuellen Zeile innerhalb ihrer Partition mit Lücken zurück. Peers gelten als Gleichstand und erhalten den gleichen Rang. Diese Funktion weist Peer-Gruppen keine aufeinanderfolgenden Ränge zu, wenn Gruppen größer als eins vorhanden sind; das Ergebnis sind nicht zusammenhängende Rangnummern ."
Es scheint für diese Anforderung gut geeignet zu sein.
mysql> SELECT pipe_name, pipe_length,
-> RANK() OVER(ORDER BY pipe_length DESC) AS long_to_short
-> FROM pipe_vw;
+-------------+-------------+---------------+
| pipe_name | pipe_length | long_to_short |
+-------------+-------------+---------------+
| Joint-78344 | 44.40 | 1 |
| Joint-4841R | 25.55 | 2 |
| Joint-278 | 17.40 | 3 |
| Joint-8819 | 16.60 | 4 |
| Joint-1224C | 15.22 | 5 |
| Joint-2138 | 13.55 | 6 |
| Joint-889 | 13.00 | 7 |
| Joint-2528 | 11.50 | 8 |
| Joint-68444 | 11.34 | 9 |
| Joint-9844 | 10.40 | 10 |
| Joint-171C | 9.45 | 11 |
| Joint-98434 | 9.13 | 12 |
| Joint-122B | 7.78 | 13 |
+-------------+-------------+---------------+
13 rows in set (0.01 sec)Im nächsten Szenario möchte ich noch weiter auf dem vorherigen Beispiel aufbauen, indem ich die Aufzeichnungen von der längsten bis zur kürzesten Länge einordne, aber für jede einzelne Gruppe der unterschiedlichen wall_thickness-Werte.
Vielleicht erklären die folgende Abfrage und die Ergebnisse besser, wo meine Prosa es vielleicht nicht getan hat:
mysql> SELECT pipe_name, pipe_length, wall_thickness,
-> RANK() OVER(PARTITION BY wall_thickness ORDER BY pipe_length DESC) AS long_to_short
-> FROM pipe_vw;
+-------------+-------------+----------------+---------------+
| pipe_name | pipe_length | wall_thickness | long_to_short |
+-------------+-------------+----------------+---------------+
| Joint-4841R | 25.55 | 0.115 | 1 |
| Joint-278 | 17.40 | 0.393 | 1 |
| Joint-9844 | 10.40 | 0.393 | 2 |
| Joint-8819 | 16.60 | 0.427 | 1 |
| Joint-2528 | 11.50 | 0.427 | 2 |
| Joint-78344 | 44.40 | 0.893 | 1 |
| Joint-1224C | 15.22 | 0.893 | 2 |
| Joint-2138 | 13.55 | 0.893 | 3 |
| Joint-889 | 13.00 | 0.893 | 4 |
| Joint-68444 | 11.34 | 0.893 | 5 |
| Joint-171C | 9.45 | 0.893 | 6 |
| Joint-98434 | 9.13 | 0.893 | 7 |
| Joint-122B | 7.78 | 0.893 | 8 |
+-------------+-------------+----------------+---------------+
13 rows in set (0.00 sec)Diese Abfrage verwendet die Klausel PARTITION BY für die Spalte wall_thickness, weil wir die Rangordnung (die ORDER BY pipe_length DESC liefert) wollen, wir sie jedoch im Kontext der einzelnen wall_thickness-Gruppen benötigen.
Jede long_to_short-Spaltenrangfolge wird auf 1 zurückgesetzt, wenn Sie auf einen anderen wall_thickness-Spaltenwert stoßen (oder sich ändern).
Konzentrieren wir uns auf die Ergebnisse einer einzelnen Gruppe.
Auf die Datensätze mit wall_thickness-Werten von 0,893 abzielend, hat die Zeile mit pipe_length 44,40 eine entsprechende long_to_short-Rangfolge von 1 (sie ist die längste), während die Zeile mit pipe_length 7,78 eine entsprechende long_to_short-Rangfolge von 8 (die kürzeste) hat, die alle darin enthalten ist spezifische Gruppe (0,893) von wall_thickness-Werten.
Fensterfunktionen sind ziemlich mächtig und ihr gesamter Umfang und ihre Breite könnte unmöglich in einem Abschnitt allein abgedeckt werden. Besuchen Sie unbedingt die Dokumentation zu unterstützten Fensterfunktionen in MySQL 8, um weitere Informationen zu den derzeit verfügbaren Funktionen zu erhalten.
Verbesserte räumliche Unterstützung und Fähigkeiten
Dies ist eine enorme Menge an Funktionen, die in MySQL 8 enthalten sind. Die Unterstützung früherer Versionen oder deren Fehlen war einfach nicht vergleichbar mit Implementierungen anderer Anbieter (denken Sie an PostGIS für PostgreSQL).
In den letzten mehr als 10 Jahren habe ich vor Ort als Pipeline-Sachverständiger gearbeitet und GPS- und Anlagendaten gesammelt, daher erregt diese Gruppe von Änderungen definitiv meine Aufmerksamkeit.
Geodaten-Expertise ist ein umfassendes Thema für sich und seien Sie versichert, ich bin weit davon entfernt, ein Experte darin zu sein. Ich hoffe jedoch, die wesentlichen Änderungen zwischen den Versionen 5.7 und 8 zusammenfassen und klar und prägnant vermitteln zu können.
Machen wir uns für die Zwecke dieses Abschnitts mit 2 Schlüsselbegriffen (und Konzepten) vertraut.
-
Spatial Reference System oder SRS – Hier ist eine teilweise Definition aus Wikipedia:
„Ein räumliches Bezugssystem (SRS) oder Koordinatenbezugssystem (CRS) ist ein koordinatenbasiertes lokales, regionales oder globales System, das zur Lokalisierung geografischer Einheiten verwendet wird. Ein räumliches Bezugssystem definiert eine bestimmte Kartenprojektion sowie Transformationen zwischen verschiedenen räumlichen Bezügen Systeme."
-
Spatial Reference System Identifier oder SRID – Auch Wikipedia hat SRIDs wie folgt definiert:
"Ein Spatial Reference System Identifier (SRID) ist ein eindeutiger Wert, der verwendet wird, um projizierte, nicht projizierte und lokale räumliche Koordinatensystemdefinitionen eindeutig zu identifizieren. Diese Koordinatensysteme bilden das Herzstück aller GIS-Anwendungen."
MySQL unterstützt viele räumliche Datentypen. Einer der häufigsten ist ein Punkt. Wenn Sie Ihr GPS verwenden, um zu Ihrem Lieblingsrestaurant zu navigieren, ist dieser Ort ein PUNKT auf einer Karte.
MySQL 5.7 behandelt so ziemlich jedes 'räumliche Objekt ' mit einer SRID von 0, was für Berechnungen von Bedeutung ist. Diese Berechnungen werden in einem kartesischen Koordinatensystem berechnet. Wir alle wissen jedoch, dass unser Globus eine Kugel ist und alles andere als flach. Daher haben Sie in Version 8 die Möglichkeit, es in Berechnungen entweder als flach oder als kugelförmig zu betrachten.
Zurück zu diesen beiden Begriffen, die wir zuvor definiert haben.
Obwohl 0 die Standard-SRID in MySQL-Version 8 ist, werden viele (ca. 5.000+) andere SRIDs unterstützt.
Aber warum ist das wichtig?
Diese fantastische Erklärung aus dem Blog-Beitrag Spatial Reference Systems in MySQL 8.0 fasst es gut zusammen:
"Wenn wir keine SRID angeben, erstellt MySQL standardmäßig Geometrien in SRID 0. SRID 0 ist MySQLs Vorstellung einer abstrakten, einheitenlosen, unendlichen, katesischen Ebene. Während alle anderen SRSs sich auf eine Oberfläche beziehen und Einheiten für die definieren Achsen, SRID 0 nicht."
Im Wesentlichen, wenn Berechnungen mit SRIDs anders als SRID 0 durchgeführt werden , dann kommt die Form unserer Erde ins Spiel, wird berücksichtigt und beeinflusst diese Berechnungen. Dies ist entscheidend für sinnvolle/genaue Berechnungen. Einen detaillierten Überblick und eine bessere Extrapolation finden Sie in diesem Blog-Beitrag zur Geographie in MySQL 8.
Ich empfehle auch dringend den Blogbeitrag des MySQL Server-Teams, Geographic Spatial Reference Systems in MySQL 8.0, um mehr Klarheit über SRS zu erhalten. Stellen Sie sicher und lesen Sie es!
Zu guter Letzt, bei Problemen mit dem Upgrade räumlicher Daten von Version 5.7 auf 8, besuchen Sie einige der inkompatiblen Änderungen, die hier aufgelistet sind, um weitere Informationen zu erhalten.
Andere bemerkenswerte Beobachtungen
Unten sind weitere Release-Verbesserungen aufgeführt, die ich anerkennen muss, obwohl sie in diesem Blogbeitrag nicht ausführlich behandelt werden:
- utf8mb4 ist jetzt der Standardzeichensatz (früher latin1) - Bessere Unterstützung für diejenigen, die Emojis zusätzlich zu einigen Sprachen haben müssen...
- Transactional Data Dictionary - MySQL-Metadaten sind jetzt in InnoDB-Tabellen untergebracht.
- Unsichtbare Indizes – Legen Sie die Sichtbarkeit eines Index für den Optimierer fest, um letztendlich zu bestimmen, ob das Hinzufügen oder Entfernen (des Index) eine gute oder schlechte Sache ist. Das Hinzufügen eines Index zu einer vorhandenen großen Tabelle kann 'teuer sein ' in Bezug auf Sperren und Ressourcen.
- Absteigende Indizes – Bessere Leistung bei indizierten Werten, die in absteigender Reihenfolge gespeichert werden.
- Instant Add Column – Geben Sie für Schemaänderungen ALGORITHM=INSTANT in ALTER TABLE-Anweisungen an und vermeiden Sie (sofern für die Operation möglich) Metadatensperren. (Weitere Informationen finden Sie in diesem großartigen Beitrag des MySQL Server-Teams und im Abschnitt ALTER TABLE der offiziellen Dokumentation.)
Bonusteil:Etwas, das ich zu sehen gehofft hatte...
Zugehörige Ressourcen ClusterControl for MySQL Werden Sie eine MySQL-DBA-Blogserie – Allgemeine Vorgänge – Änderungen der Replikationstopologie Werden Sie eine MySQL-DBA-Blogserie – Datenbank-UpgradesCheck Constraints haben noch nicht ihren Weg in das MySQL-Produkt gefunden.
Wie bei früheren MySQL-Versionen ist die Check-Constraint-Syntax in Ihren CREATE TABLE-Befehlen erlaubt, wird aber ignoriert. Meines Wissens unterstützen die meisten anderen SQL-Anbieter Check Constraints. Kommen Sie zur MySQL-Party!
MySQL hat sich erheblich 'aufgewertet ' sein Angebot in Version 8. Unter den zahlreichen zusätzlichen Verbesserungen ist die Unterstützung robuster räumlicher Fähigkeiten, komfortabler Benutzerverwaltungsrollenoptionen, "hybrider" SQL/NoSQL-Datenlösungen und analytischer Funktionen wirklich bemerkenswert.
Meiner Meinung nach bietet MySQL mit Version 8 weiterhin eine solide Option im ständig wachsenden, wettbewerbsorientierten Open-Source-SQL-Ökosystem, voll von relevanten und funktionsreichen Lösungen.
Danke fürs Lesen.
