Wir erwägen die Verwendung von UUID-Werten als Primärschlüssel für unsere MySQL-Datenbank. Die Daten, die eingefügt werden, werden von Dutzenden, Hunderten oder sogar Tausenden von entfernten Computern generiert und mit einer Rate von 100-40.000 Einfügungen pro Sekunde eingefügt, und wir werden nie irgendwelche Aktualisierungen vornehmen.
Die Datenbank selbst wird in der Regel etwa 50 Mio. Datensätze umfassen, bevor wir beginnen, die Daten zu bereinigen, also keine riesige Datenbank, aber auch keine winzige. Wir planen auch auf InnoDB zu laufen, obwohl wir offen sind, das zu ändern, wenn es eine bessere Engine für das, was wir tun, gibt.
Wir waren bereit, mit Java's Type 4 UUID zu arbeiten, aber beim Testen haben wir ein seltsames Verhalten festgestellt. Zum einen speichern wir als varchar(36) und ich erkenne jetzt, dass wir mit binary(16) besser dran wären - aber wie viel besser dran ist, weiß ich nicht.
Die wichtigere Frage ist: Wie stark beeinträchtigen diese Zufallsdaten den Index, wenn wir 50 Millionen Datensätze haben? Wären wir besser dran, wenn wir zum Beispiel eine UUID vom Typ 1 verwenden würden, bei der die äußersten linken Bits mit einem Zeitstempel versehen sind? Oder sollten wir die UUIDs vielleicht ganz weglassen und automatische Primärschlüssel in Betracht ziehen?
Ich bin auf der Suche nach allgemeinen Gedanken/Tipps zur Leistung verschiedener Arten von UUIDs, wenn sie als Index/Primärschlüssel in MySQL gespeichert werden. Vielen Dank!
