it-swarm.com.de

Die Unterschiede zwischen INT und UUID in MySQL

Wenn ich den Primärschlüssel als INT-Typ (AUTO_INCREMENT) oder in UUID einstelle, was ist der Unterschied zwischen diesen beiden in der Datenbankleistung (SELECT, INSERT usw.) und warum?

15
孙为强

UUID gibt einen universellen eindeutigen Bezeichner zurück (hoffentlich auch eindeutig, wenn auch in einen anderen DB importiert).

So zitieren Sie aus MySQL doc (Hervorhebungsmethode):

Eine UUID ist eine Zahl, die global eindeutig im Raum und Time ist. Es wird erwartet, dass zwei Aufrufe von UUID () zwei verschiedene - Werte erzeugen, , auch wenn diese Aufrufe auf zwei separaten Computern Ausgeführt werden, die nicht miteinander verbunden sind.

Auf der anderen Seite gibt ein INT primärer ID-Schlüssel (z. B. AUTO_INCREMENT) einen eindeutigen Integer für den spezifischen DB und die DB-Tabelle zurück, der jedoch nicht universell eindeutig ist ( Wenn Sie also in eine andere DB importiert werden, kann es zu Primärschlüsselkonflikten kommen.

In Bezug auf die Leistung sollte es keinen merklichen Unterschied geben, wenn auto-increment über UUID verwendet wird. Die meisten Beiträge (einschließlich einiger von den Autoren dieser Website) sind als solche angegeben. Natürlich benötigt UUID etwas mehr Zeit (und Speicherplatz), aber dies ist in den meisten (wenn nicht allen) Fällen kein Leistungsengpass. Mit einer Spalte als Primary Key sollten beide Optionen in Bezug auf die Leistung gleich sein. Referenzen siehe unten:

  1. Zu UUID oder nicht zu UUID?
  2. Mythen, GUID vs. Autoincrement
  3. Leistung: UUID vs. auto-increment in cakephp-mysql
  4. UUID Leistung in MySQL?
  5. Primärschlüssel: IDs versus GUIDs (Coding Horror)

(UUID vs. auto-increment Leistungsergebnisse, angepasst aus Mythen, GUID vs. Autoincrement )

enter image description here

UUID pros/cons (angepasst von Primärschlüssel: IDs versus GUIDs )

GUID Pros

  • Einzigartig für jede Tabelle, jede Datenbank, jeden Server
  • Ermöglicht das einfache Zusammenführen von Datensätzen aus verschiedenen Datenbanken
  • Ermöglicht die einfache Verteilung von Datenbanken auf mehrere Server
  • Sie können IDs an beliebiger Stelle generieren, anstatt einen Roundtrip zur Datenbank durchführen zu müssen
  • Die meisten Replikationsszenarien erfordern GUID Spalten

GUID Nachteile

  • Er ist um das Vierfache größer als der traditionelle 4-Byte-Indexwert. Dies kann schwerwiegende Auswirkungen auf die Leistung und den Speicher haben, wenn Sie nicht aufpassen
  • Umständliches Debuggen (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
  • Die generierten GUIDs sollten für eine optimale Leistung teilweise sequenziell sein (z. B. newsequentialid() in SQL 2005) und die Verwendung von Clustered-Indizes ermöglichen.


Hinweis

Ich würde die erwähnten Referenzen sorgfältig lesen und entscheiden, ob ich UUID verwenden sollte oder nicht, abhängig von meinem Anwendungsfall. In vielen Fällen wäre UUIDs jedoch vorzuziehen. Beispielsweise kann man UUIDs generieren, ohne auf die Datenbank zuzugreifen oder überhaupt auf die Datenbank zuzugreifen, oder sogar UUIDs, die vorberechnet und/oder woanders gespeichert wurden. Darüber hinaus können Sie Ihr Datenbank- und/oder Clustering-Schema einfach verallgemeinern/aktualisieren, ohne dass Sie sich Sorgen machen müssen, dass IDs beschädigt wird und Konflikte verursacht.

27
Nikos M.

Ein UUID-Schlüssel kann nicht pk sein, es sei denn, er bleibt in der DB bestehen. Die Rundenumschaltung erfolgt dann, bis Sie den pk ohne erfolgreiche Transaktion nicht annehmen können. Die meisten UUIDs verwenden zeitbasierte, macbasierte, namenbasierte oder eine zufällige Uuid. In Anbetracht dessen, dass wir uns stark auf Container-basierte Implementierungen konzentrieren, haben sie ein Muster für den Start von MAC-Adressen, die auf MAC-Adressen angewiesen sind, funktionieren nicht. Zeitbasiert kann nicht garantiert werden, da davon ausgegangen wird, dass Systeme immer auf exakte Zeitsynchronisation eingestellt sind, was manchmal nicht der Fall ist, da Uhren den Regeln nicht folgen. GUID kann nicht garantieren, dass es nie zu einer Kollision kommt, nur wenn dies in einer kurzen Zeitspanne nicht der Fall ist, sondern ausreichend Zeit und Systeme, die parallel laufen, und die Verbreitung von Systemen, die garantieren, dass sie letztendlich versagen. [ http://www.ietf.org/rfc/rfc4122.txt]

1
Rohitdev