Rendimiento MySQL del campo varchar único frente a bigint único

Question

Estoy trabajando en una aplicación que implementará un valor hexadecimal como clave comercial (además de un campo de incremento automático como clave principal) similar al ID de URL que se ve en Gmail . Agregaré una restricción única a la columna y originalmente estaba pensando en almacenar el valor como un gran paso para alejarme de la búsqueda de un campo varchar, pero me preguntaba si eso es necesario si el campo es único.

Las uniones internas se realizarían utilizando el campo de incremento automático y el valor hexadecimal se usaría en la cláusula where para el filtrado.

¿Qué tipo de golpe de rendimiento habría en simplemente almacenar el valor como varchar (x), o tal vez un char (x) sobre el trabajo adicional al hacer la conversión hacia y desde hex para almacenar el valor como un entero en la base de datos? ¿Vale la pena la complejidad adicional?

Hice una prueba rápida en un pequeño número de filas (50k) y tuve tiempos de búsqueda similares. Si hay un gran problema de rendimiento, ¿sería lineal o exponencial?

Estoy usando InnoDB como motor.

Answer 1

¿Su valor hexadecimal es un GUID? Aunque solía preocuparme por el rendimiento de elementos tan largos como los índices, he descubierto que en las bases de datos modernas, la diferencia de rendimiento incluso en millones de registros es bastante insignificante.

Un problema potencialmente más grande es la memoria que consume el índice (16 bytes frente a 4 bytes int, por ejemplo), pero en los servidores que yo controlo puedo asignar para eso. Siempre que el índice pueda estar en la memoria, me parece que hay más sobrecarga de otras operaciones que el tamaño del elemento índice no hace una diferencia notable.

Por el lado positivo, si usa un GUID obtiene independencia de servidor para los registros creados y más flexibilidad para combinar datos en varios servidores (que es algo que me importa, ya que nuestro sistema agrega datos de sistemas secundarios).

Hay un gráfico en este artículo que parece respaldar mi sospecha: Myths, GUID vs Autoincrement

Answer 2

Se genera el valor hexadecimal de un UUID (aplicación Java); es hash y truncado a una longitud menor (probablemente 16 caracteres). El algoritmo para el cual todavía está en discusión (actualmente SHA). Una ventaja que veo al almacenar el valor en hexadecimales frente a enteros es que si necesitábamos hacer crecer el tamaño (que no veo que ocurra con esta aplicación a 16 caracteres) simplemente podríamos aumentar la longitud truncada y dejar los valores anteriores sin miedo de colisión La conversión a valores enteros no funcionaría tan bien para eso.

El motivo del truncamiento vs simplemente usar un GUID/UUID es simplemente hacer que las URL y las API (que es donde se usarán) sean más amigables.

Answer 3

En igualdad de condiciones, mantener los datos más pequeños hará que funcione más rápido. Principalmente porque tomará menos espacio, por lo tanto, menos disco de E/S, menos memoria necesaria para mantener el índice, etc. etc. 50k filas no es suficiente para notar que ...