Le differenze tra INT e UUID in MySQL

UUID restituisce un identificatore univoco universale (si spera anche univoco se importato anche in un altro DB).

Per citare da MySQL doc (enfasi mia):

D'altra parte semplicemente un INT chiave ID primaria (ad es. AUTO_INCREMENT ) restituirà un numero intero univoco per la tabella DB e DB specifica, ma che non è universalmente univoca (quindi se importato in un altro DB è probabile che ci siano conflitti di chiave primaria).

In termini di prestazioni, non dovrebbero esserci differenze evidenti utilizzando l'auto-increment su UUID . La maggior parte dei post (compresi alcuni degli autori di questo sito) affermano come tali. Ovviamente UUID potrebbe richiedere un po' più di tempo (e spazio), ma questo non è un collo di bottiglia delle prestazioni per la maggior parte (se non tutti) i casi. Avere una colonna come Primary Key dovrebbe rendere entrambe le scelte uguali rispetto alle prestazioni. Vedi riferimenti sotto:

1. A UUID o meno a UUID ?
2. Miti, GUID vs Autoincrement
3. Prestazioni:UUID vs auto-increment in cakephp-mysql
4. UUID prestazioni in MySQL?
5. Chiavi primarie:ID s contro GUID s (codifica dell'orrore)

(UUID vs auto-increment risultati delle prestazioni, adattati da Miti, GUID vs Autoincrement )

UUID pro/contro (adattato da Chiavi primarie:ID s contro GUID s )

Nota

Leggerei attentamente i riferimenti citati e deciderei se utilizzare UUID o meno a seconda del mio caso d'uso. Detto questo, in molti casi UUID s sarebbe davvero preferibile. Ad esempio si può generare UUID s senza usare/accedere al database, o addirittura usare UUID s che sono stati precalcolati e/o archiviati da qualche altra parte. Inoltre puoi facilmente generalizzare/aggiornare lo schema del database e/o lo schema di clustering senza doversi preoccupare dell'ID s rompere e causare conflitti.

In termini di possibili collisioni, ad esempio utilizzando UUIDS v4 (random), la probabilità di trovare un duplicato entro 103 trilioni di UUID versione 4 è uno su un miliardo.