Prestazioni MySQL di campo varchar unico vs bigint unico

Question

Sto lavorando a un'applicazione che implementerà un valore esadecimale come chiave aziendale (oltre a un campo di incremento automatico come chiave primaria) simile all'ID URL visualizzato in Gmail . Aggiungerò un vincolo univoco alla colonna e inizialmente pensavo di memorizzare il valore come un bigint per evitare la ricerca in un campo varchar, ma mi chiedevo se è necessario se il campo è unico.

I join interni verranno eseguiti utilizzando il campo di incremento automatico e il valore esadecimale verrà utilizzato nella clausola where per il filtro.

Che tipo di perdita di prestazioni ci sarebbe nella semplice memorizzazione del valore come varchar (x), o forse un char (x) sul lavoro aggiuntivo nel fare la conversione da e verso hex per memorizzare il valore come numero intero nel database? Vale la complessità aggiuntiva?

Ho eseguito un test rapido su un numero limitato di righe (50k) e ho ottenuto risultati di ricerca simili. Se c'è un grosso problema di prestazioni sarebbe lineare o esponenziale?

Sto utilizzando InnoDB come motore.

Answer 1

Il valore esadecimale è un GUID? Sebbene mi preoccupassi delle prestazioni di articoli così lunghi come gli indici, ho riscontrato che nei database moderni la differenza di prestazioni su milioni di record è abbastanza insignificante.

Un problema potenzialmente più grande è la memoria che l'indice consuma (16 byte contro 4 byte int, ad esempio), ma sui server che controllo posso allocare per quello. Finché l'indice può essere in memoria, trovo che ci sono più overhead da altre operazioni che la dimensione dell'elemento index non fa una differenza evidente.

Sul lato positivo, se si utilizza un GUID si ottiene l'indipendenza del server per i record creati e una maggiore flessibilità nell'unione dei dati su più server (che è qualcosa a cui tengo, dato che il nostro sistema aggrega i dati dai sistemi figli).

C'è un grafico in questo articolo che sembra per eseguire il backup il mio sospetto: Myths, GUID vs Autoincrement

Answer 2

Il valore esadecimale viene generato da un UUID (implementazione di Java); è hash e troncato a una lunghezza inferiore (probabilmente 16 caratteri). L'algoritmo per il quale è ancora in discussione (attualmente SHA). Un vantaggio che vedo di memorizzare il valore in hex vs intero è che se avessimo bisogno di aumentare la dimensione (che non vedo accadendo con questa applicazione a 16 caratteri) potremmo semplicemente aumentare la lunghezza troncata e lasciare i vecchi valori senza paura di collisione. La conversione in valori interi non funzionerebbe altrettanto bene.

Il motivo del troncamento rispetto all'utilizzo semplicemente di un GUID/UUID è semplicemente quello di rendere più amichevoli gli URL e le API (che sono dove verranno utilizzati).

Answer 3

A parità di tutti gli altri, mantenere i dati più piccoli lo farà correre più velocemente. Principalmente perché richiede meno spazio, quindi meno I/O del disco, meno memoria necessaria per contenere l'indice, ecc. 50k righe non sono sufficienti per notare che però ...