Le differenze tra int e uuid in mysql

Question

Se ho impostato la chiave primary id a int tipo (auto increment) o impostarlo in UUID, qual è la differenza tra questi due nel prestazioni del database (select, insert ...) e perché?

Answer 1

UUID restituisce un universal unique identifier (hopefuly unica anche se importati ad un altro DB pure)

citare mysql doc (sottolineatura mia):

Un UUID è concepito come un numero che è globalmente unico nello spazio e tempo . Due chiamate a UUID() dovrebbero generare due diversi valori , anche se queste chiamate vengono eseguite su due computer separati non collegati tra loro.

D'altra parte una chiave id semplicemente INT primaria (es autoincrement) restituirà un numero intero univocoper la specifica tabella DB e DB, ma che è non universaly univoco (quindi se importato in un altro DB è probabile che ci siano conflitti chiave primari)

In termini di prestazioni, non ci dovrebbero essere differenze evidenti utilizzando auto-increment su UUID. La maggior parte dei post (inclusi alcuni degli autori di questo sito), lo dichiarano come tali. Ovviamente lo UUID potrebbe richiedere un po 'più di tempo (e spazio), ma questo non è un collo di bottiglia per le prestazioni per la maggior parte dei casi (se non tutti). Avere una colonna come Primary Key dovrebbe rendere entrambe le opzioni equivalenti alla performance.Vedere i riferimenti di seguito:

1. To UUID or not to UUID?
2. Myths, GUID vs Autoincrement
3. Performance: UUID vs auto-increment in cakephp-mysql
4. UUID performance in MySQL?
5. Primary Keys: IDs versus GUIDs (coding horror)

(UUID vs auto-increment risultati di performance, adattati da Myths, GUID vs Autoincrement)

UUID pro/contro (adattato da Primary Keys: IDs versus GUIDs)

GUID Pro

• univoco in ogni tavolo, tutti i database, tutti i server
• permette una facile fusione di record da diversi database
• consente una facile distribuzione di banche dati su più server
• È possibile generare ID s ovunque, invece di dover andata e ritorno per il database
• maggior parte degli scenari di replica richiedono GUID colonne comunque

GUID Contro

• È un enorme 4 volte più grande del tradizionale valore dell'indice a 4 byte; questo può avere gravi implicazioni sulle prestazioni e di stoccaggio se non stai attento
• ingombrante per eseguire il debug (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• Le generati GUID s dovrebbe essere parzialmente sequenziale per le migliori prestazioni (ad esempio, newsequentialid() su SQL 2005) e per consentire l'uso degli indici cluster .

Nota vorrei leggere attentamente i riferimenti citati e decidere se utilizzare o meno UUID a seconda del mio caso d'uso. Detto questo, in molti casi sarebbe preferibile lo UUID s. Ad esempio, è possibile generare UUID s senza utilizzare/accedere al database o utilizzare anche UUID s che sono stati pre-calcolati e/o memorizzati altrove. Inoltre puoi facilmente generalizzare/aggiornare lo schema del tuo database e/o lo schema di clustering senza doversi preoccupare dell'irruzione di ID s e causare conflitti.