Der Unterschied sowie die Vor- und Nachteile des MySQL-Primärschlüssels UUID und des automatisch inkrementierten Primärschlüssels

Einführung

Ich habe eine Zeit lang die PostgreSQL-Datenbank verwendet. Nach dem Wechsel in die Cloud habe ich vom automatisch inkrementierten Primärschlüssel auf UUID umgestellt. Ich finde, dass UUID global eindeutig und sehr praktisch ist.

Ich habe kürzlich MySQL verwendet und festgestellt, dass alle MySQL-Primärschlüssel automatisch inkrementierte Primärschlüssel sind. Nach sorgfältigem Vergleich habe ich herausgefunden, warum MySQL automatisch inkrementierte Primärschlüssel wählt und was die Unterschiede sind.

Vor MySQL 5.0 können automatisch inkrementierte Primärschlüssel nicht verwendet werden, wenn mehrere Master-Replikationsumgebungen vorhanden sind, da diese dupliziert werden können. In den Versionen 5.0 und höher wird das gesamte Problem durch die Konfiguration eines Auto-Inkrement-Offsets gelöst.

Unter welchen Umständen möchten wir UUID verwenden?

1. Vermeiden Sie Duplikate und erleichtern Sie die Skalierung. Dies ist der Hauptgrund, warum wir beim Erstellen von Cloud-Diensten UUID wählen.

2. Sie können die ID kennen, bevor Sie das Lager betreten

3. Relativ sicher. Sie können nicht einfach Informationen aus der UUID abrufen. Wenn sie sich jedoch selbst erhöht, können Informationen leicht offengelegt werden. Wenn eine Kunden-ID 123456 lautet, lässt sich leicht erraten, dass es eine Kunden-ID mit der Nummer 123456 gibt.

Was ist falsch an UUID

1. UUID hat 16 Bytes, was mehr Speicherplatz beansprucht als int (4 Bytes) und bigint (8 Bytes)

2. Aufgrund von Größe und Unordnung können Leistungsprobleme auftreten

Mysql-UUID-Prinzip

Die InnoDB-Speicher-Engine von MySQL verwaltet den Speicher über gruppierte Indizes.

Von einem gruppierten Index spricht man, wenn die physische Reihenfolge der Daten in den Zeilen der Datenbanktabelle mit der logischen (Index-)Reihenfolge der Schlüsselwerte übereinstimmt. Eine Tabelle kann nur einen gruppierten Index haben, da die physische Reihenfolge einer Tabelle nur einen Fall umfassen kann.

1. Warum UUID als Primärschlüssel verwenden?

(1) Tatsächlich hat die Leistung der selbstinkrementierenden ID als Primärschlüssel unter der InnoDB-Speicher-Engine die beste erreicht. Sowohl die Speicher- als auch die Lesegeschwindigkeit sind am höchsten und der belegte Speicherplatz ist am geringsten.

(2) Im tatsächlichen Projekt treten jedoch Probleme auf. Die Primärschlüssel-ID der historischen Datentabelle wird mit der ID der Datentabelle wiederholt. Wenn zwei Tabellen mit automatisch inkrementierten IDs als Primärschlüssel zusammengeführt werden, treten definitiv ID-Konflikte auf. Wenn die jeweiligen IDs jedoch auch mit anderen Tabellen verknüpft sind, ist dies sehr schwierig zu handhaben.

(3) Wenn UUID verwendet wird, ist die generierte ID nicht nur tabellenunabhängig, sondern auch datenbankunabhängig. Dies ist für zukünftige Datenvorgänge äußerst vorteilhaft und kann als einmalige Lösung bezeichnet werden.

2. Vor- und Nachteile von UUID

Nachteile: 1. Beeinträchtigt die Einsteckgeschwindigkeit und führt zu einer geringen Festplattenauslastung

2. Der Vergleich der Größe von UUIDs ist viel langsamer als der Vergleich von Zahlen, was sich auf die Abfragegeschwindigkeit auswirkt.

3. UUID nimmt viel Platz ein. Je mehr Indizes Sie erstellen, desto schwerwiegender sind die Auswirkungen.

Vorteile: Wenn Daten zur Speicherung aufgeteilt und zusammengeführt werden, kann globale Eindeutigkeit erreicht werden

3. Beste Lösung

(1). Die InnoDB-Engine-Tabelle ist eine indexorganisierte Tabelle, die auf einem B+-Baum basiert.

(2) B + -Baum: Der B + -Baum ist ein ausgeglichener Suchbaum, der für Festplatten oder andere Hilfsgeräte mit direktem Zugriff entwickelt wurde. Im B + -Baum werden alle Datensatzknoten in der Reihenfolge des Schlüsselwerts in den Blattknoten derselben Ebene gespeichert, und die Blattknotenzeiger sind verbunden.

(3). InnoDB-Primärindex: Der Blattknoten enthält vollständige Datensätze. Dieser Indextyp wird als gruppierter Index bezeichnet. InnoDB-Indizes ermöglichen eine sehr schnelle Suche nach Primärschlüsseln. Die sekundären Indizes enthalten jedoch auch die Primärschlüsselspalten. Wenn also der Primärschlüssel als groß definiert ist, sind auch die anderen Indizes groß. Wenn Sie viele Indizes für eine Tabelle definieren möchten, versuchen Sie, den Primärschlüssel so klein wie möglich zu definieren. InnoDB komprimiert keine Indizes

(4) Diese Implementierungsmethode des Clustered-Index macht die Suche nach Primärschlüsseln sehr effizient, für die Suche nach Hilfsindexen sind jedoch zwei Indexsuchen erforderlich: Durchsuchen Sie zuerst den Hilfsindex, um den Primärschlüssel zu erhalten, und durchsuchen Sie dann mit dem Primärschlüssel den Primärindex, um den Datensatz zu erhalten.

Auf der Grundlage des oben Gesagten erhalten wir:

(1) Wenn die Datenschreibreihenfolge der InnoDB-Tabelle mit der Blattknotenreihenfolge des B+-Baumindex übereinstimmt, ist die Zugriffseffizienz am höchsten. Aus Speicher- und Abfragegründen sollten Sie die selbstinkrementierende ID als Primärschlüssel verwenden.

(2) Für den Primärindex von InnoDB werden die Daten nach dem Primärschlüssel sortiert. Aufgrund der Unordnung der UUID erzeugt InnoDB einen enormen IO-Druck. Derzeit ist es nicht geeignet, die UUID als physischen Primärschlüssel zu verwenden. Sie kann als logischer Primärschlüssel verwendet werden. Der physische Primärschlüssel verwendet weiterhin die Auto-Inkrement-ID. Zur Gewährleistung globaler Eindeutigkeit sollte die UUID als Index zum Verknüpfen anderer Tabellen oder als Fremdschlüssel verwendet werden.

4. Wenn Sie UUID als Primärschlüssel verwenden müssen, hier einige Vorschläge:

Im Master-Slave- oder MS-Modus sollten Sie die integrierte UUID-Funktion von MySQL nicht zum Generieren eines eindeutigen Primärschlüssels verwenden, da beim Verknüpfen der von der Mastertabelle generierten UUID mit der Slavetabelle die Datenbank zum Ermitteln der UUID aufgerufen werden muss, was eine weitere Datenbankinteraktion erfordert. Während dieser Zeitspanne generiert die Mastertabelle wahrscheinlich Daten, was leicht zu Fehlern in der verknüpften UUID führen kann. Wenn Sie die UUID wirklich verwenden möchten, können Sie sie in Java generieren und direkt in der Datenbank speichern. Zu diesem Zeitpunkt sind die UUIDs von Master und Slave identisch!

Ergänzung: MySQLs uuid()-Primärschlüssel wird wiederholt

1. Der uuid()-Primärschlüssel von mysql wird wiederholt

MySQL verwendet den Navicat-Client und führt einmal die folgende SQL aus

Wählen Sie „Ersetzen (uuid (), „-“, „“) als ID, u.user_id von t_user u;“

Es stellte sich heraus, dass die generierte UUID wiederholt wurde.

Nach einer Untersuchung stellte sich heraus, dass es sich um ein Problem mit Navicat handelte. Die SQL-Anweisung musste wie folgt angepasst werden:

Wählen Sie „Ersetzen (Konvertieren (uuid() mit utf8mb4), '-', ''), u.user_id von t_user u“;

Die Ergebnisse sind wie folgt:

2. Verwenden Sie andere Lösungen:

Führen Sie MD5 erneut für die UUID aus:

Wähle md5(uuid()) als ID, u.user_id von t_user u;

Das Obige ist meine persönliche Erfahrung. Ich hoffe, es kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden. Sollten dennoch Fehler oder unvollständige Überlegungen vorliegen, freue ich mich über eine Korrektur.