mysql - ejemplo - ¿Por qué ENUM es mejor que INT?

mysql data types

Question

Acabo de ejecutar un "PROCEDURE ANALYZE ()" en una de mis tablas. Y tengo esta columna que es de tipo INT y solo contiene valores del 0 al 12 (ID de categoría). Y MySQL dijo que sería mejor con un ENUM (''0'', ''1'', ''2'', ..., ''12''). Las categorías de esta categoría son básicamente estáticas y no cambiarán en el futuro, pero si lo hacen, puedo modificar esa columna y agregarla a la lista ENUM ...

Entonces, ¿por qué ENUM es mejor en este caso?

editar: me interesa sobre todo el aspecto de rendimiento de esto ...

Answer 1

¡Ay! Hay un montón de ambigüedades con el uso de números en un campo ENUM . Ten cuidado. Lo único que recuerdo es que puedes acceder a los valores en ENUMS por índice: si tu enumeración es ENUM(''A'', ''B'', ''C'', ''1'', ''2, ''3'') , entonces estas dos consultas son muy diferentes:

INSERT INTO TABLE (example_col) VALUES( ''1'' ); -- example_col == 1
INSERT INTO TABLE (example_col) VALUES(  1  ); -- example_col == A

Supongo que la recomendación es porque limita los valores válidos que pueden entrar en la mesa. Por ejemplo, insertar 13 debería tener la opción predeterminada.

Una mejor opción sería utilizar TINYINT lugar de INT . un UNSIGNED TINYINT tiene un rango de 0 a 255 y solo requiere 1 byte para almacenar . Una INT toma 4 bytes para almacenar. Si desea restringir los valores que entran en la tabla, puede agregar los ON INSERT y ON UPDATE que verifican los valores.

Si le preocupa la diferencia de rendimiento entre ENUM y TINYINT , siempre puede comparar para ver los diferentes. Este artículo parece algo relevante.

Answer 2

En Oracle tendría un índice BITMAP que es mucho más rápido que una búsqueda basada en hash para una cantidad tan pequeña de valores. (Por lo tanto, supongo que hay un beneficio similar en la optimización de consultas o la indexación está disponible para MySQL).

Curiosamente, los documentos de MySQL sugieren que usar ''cosas que parecen números'' es una mala opción para el tipo ENUM debido a la posible confusión entre el valor enum y el índice enum ( http://dev.mysql.com/doc/refman/5.0 /en/enum.html ).

Answer 3

No soy un experto en MySQL, pero creo que los enteros siempre ocupan cuatro bytes de espacio donde las enumeraciones ocupan distintas cantidades de espacio según el rango de datos necesarios. Como solo necesita 13 elementos, podría salirse con la suya usando 1 byte para su columna.

Answer 4

Porque introduce una restricción en los valores posibles.

Answer 5

En pocas palabras, es porque está indexado de una manera diferente.

En este caso, ENUM dice "Es uno de estos 13 valores", mientras que INT dice "Podría ser cualquier número entero".

Esto significa que la indexación es más fácil, ya que no tiene que tener en cuenta la indexación de los enteros que no usa "por si acaso" alguna vez los usa.

Todo tiene que ver con los algoritmos.

Sin embargo, me interesaría cuando llegue a un punto en el que el INT sería más rápido que el ENUM .

Sin embargo, usar números en un ENUM puede ser un poco peligroso ... como si enviaras este número sin citar a SQL, ¡podrías terminar recuperando el valor equivocado!