SQL SELECT velocidad int vs varchar

Estoy en el proceso de crear una mesa y me hizo preguntarme.

Si almaceno, digamos automóviles que tienen una marca (fx BMW, Audi, etc.), ¿habrá alguna diferencia en la velocidad de consulta si almaceno la marca como int o varchar?

Asi es

SELECT * FROM table WHERE make = 5 AND ...;

Más rápido / más lento que

SELECT * FROM table WHERE make = 'audi' AND ...;

o la velocidad será más o menos la misma?

Las comparaciones de int son más rápidas que las comparaciones de varchar, por el simple hecho de que los ints ocupan mucho menos espacio que los varchars.

Esto es válido tanto para el acceso indexado como para el no indexado. La forma más rápida de hacerlo es una columna int indexada.

Como veo que ha etiquetado la pregunta postgreql, es posible que le interese el uso del espacio de diferentes tipos de fechas:

• intlos campos ocupan entre 2 y 8 bytes , siendo 4 normalmente más que suficiente (-2147483648 a +2147483647)
• los tipos de caracteres ocupan 4 bytes más las cadenas reales .

Algunos puntos de referencia aproximados:

4 millones de registros en Postgres 9.x

Table A = base table with some columns
Table B = Table A + extra column id of type bigint with random numbers
Table C = Table A + extra column id of type text with random 16-char ASCII strings

Resultados en portátiles de 8GB RAM, i7, SSD:

Size on disk:                A=261MB        B=292MB        C=322MB
Non-indexed by id: select count(*), select by id: 450ms same on all tables
Insert* one row per TX:       B=9ms/record        C=9ms/record
Bulk insert* in single TX:    B=140usec/record    C=180usec/record
Indexed by id, select by id:  B=about 200us       C=about 200us

* inserts to the table already containing 4M records

por lo que parece que para esta configuración, siempre que sus índices quepan en la RAM, el texto de bigint frente a 16 caracteres no hace ninguna diferencia en la velocidad.

Será un poco más rápido usar un int en lugar de un varchar. Más importante para la velocidad es tener un índice en el campo que la consulta pueda usar para encontrar los registros.

Hay otra razón para usar un int, y es normalizar la base de datos. En lugar de tener el texto 'Mercedes-Benz' almacenado miles de veces en la tabla, debe almacenar su identificación y guardar el nombre de la marca una vez en una tabla separada.

Desglosando el rendimiento real de la comparación de cadenas frente a no flotantes, en este caso, cualquier tamaño sin firmar y firmado no importa. El tamaño es en realidad la verdadera diferencia en el rendimiento. Ya sea 1byte + (hasta 126bytes) versus comparación de 1, 2, 4 u 8 bytes ... obviamente, los no flotantes son más pequeños que las cadenas y los flotantes y, por lo tanto, más amigables con la CPU en ensamblaje.

La comparación de cadena a cadena en todos los idiomas es más lenta que algo que la CPU puede comparar en 1 instrucción. Incluso comparar 8 bytes (64 bits) en una CPU de 32 bits es aún más rápido que un VARCHAR (2) o más. * Nuevamente, mire el ensamblaje producido (incluso a mano), se necesitan más instrucciones para comparar char por char que numérico de CPU de 1 a 8 bytes.

Ahora, ¿cuánto más rápido? depende también del volumen de datos. Si simplemente está comparando 5 con 'audi', y eso es todo lo que tiene su base de datos, la diferencia resultante es tan mínima que nunca la verá. Dependiendo de la CPU, la implementación (cliente / servidor, web / script, etc.) probablemente no lo verá hasta que alcance unos cientos de comparaciones en el servidor de base de datos (tal vez incluso un par de miles de comparaciones antes de que se note).

• Para anular la disputa incorrecta sobre las comparaciones hash. La mayoría de los algoritmos hash en sí mismos son lentos, por lo que no se beneficia de cosas como CRC64 y más pequeñas. Durante más de 12 años desarrollé algoritmos de búsqueda para motores de búsqueda de varios condados y 7 años para los burós de crédito. Cualquier cosa que pueda guardar en números más rápido ... por ejemplo, números de teléfono, códigos postales, incluso moneda * 1000 (almacenamiento) moneda div 1000 (recuperación) es más rápido que DECIMAL para las comparaciones.

Ozz

Con índice o no, int es mucho más rápido (cuanto más largo es el varchar, más lento se vuelve).

Otra razón: el índice en el campo varchar será mucho más grande que en int. Para tablas más grandes, puede significar cientos de megabytes (y miles de páginas). Eso hace que el rendimiento sea mucho peor, ya que la lectura del índice solo requiere muchas lecturas de disco.

En general, el int será más rápido. Cuanto más largo es el varchar, más lento se vuelve

Consejo: Si los valores posibles para el campo maquillaje serán nunca más (o rara vez) el cambio, puede utilizar ENUM como un compromiso. Combina buena velocidad con buena legibilidad.

Si activa la indexación en cualquiera de los campos, será más rápido. En cuanto a tu pregunta, creo que intes más rápido que varchar.

Algo relativo. Sí, los INT serán más rápidos, pero la pregunta es si se nota en su situación. ¿Son los VARCHAR solo algunas palabras pequeñas o textos más largos? y cuantas filas hay en la tabla? Si hay solo unas pocas filas, lo más probable es que esté completamente almacenado en memoria intermedia (cuando se solicite con frecuencia), en ese caso, no notará mucha diferencia. Luego, por supuesto, está la indexación, que se vuelve más importante cuando la tabla crece. Usar SSD puede ser más rápido que HD con consultas optimizadas. Además, los buenos controladores de disco a veces aceleran las consultas> 10 veces. Esto podría dejar espacio para usar VARCHAR, lo que facilita la lectura y escritura de consultas (no es necesario escribir uniones complejas) y acelera el desarrollo. Sin embargo, los puristas no estarán de acuerdo y siempre normalizarán todo.