Decimal VS Int en MySQL?

Question

¿Hay alguna diferencia de rendimiento entre el tipo decimal(10,0) unsigned y el tipo int(10) unsigned?

Answer 1

Puede depender de la versión de MySQL que esté utilizando. Ver here.

Antes de MySQL 5.0.3, el tipo DECIMAL se almacenaba como una cadena y normalmente era más lento. Sin embargo, desde MySQL 5.0.3 el tipo DECIMAL se almacena en un formato binario, por lo que con el tamaño de su DECIMAL anterior, puede que no haya mucha diferencia en el rendimiento.

El principal problema de rendimiento habría sido la cantidad de espacio ocupado por los diferentes tipos (con DECIMAL siendo más lento). Con MySQL 5.0.3+ esto parece ser un problema menor, sin embargo, si realizará cálculos numéricos en los valores como parte de la consulta, puede haber alguna diferencia en el rendimiento. Esto puede valer la pena probar ya que no hay ninguna indicación en la documentación que pueda ver.

Editar: En cuanto a la int(10) unsigned, Tomé esta a su valor nominal como simplemente ser un int 4 bytes. Sin embargo, esto tiene un valor máximo de 4294967295 que estrictamente no proporciona el mismo rango de números que DECIMAL(10,0) unsigned.

Como señaló @Unreason, necesitaría usar un bigint para cubrir el rango completo de números de 10 dígitos, empujando el tamaño hasta 8 bytes.

Un error común es que cuando se especifican tipos de columnas numéricas en MySQL, la gente a menudo piensa que el número entre paréntesis tiene un impacto en el tamaño del número que pueden almacenar. No es así El rango numérico se basa exclusivamente en el tipo de columna y si está firmado o sin firmar. El número entre paréntesis es para mostrar los resultados y no tiene ningún impacto en los valores almacenados en la columna. Tampoco tendrá ningún impacto en la visualización de los resultados a menos que especifique la opción ZEROFILL en la columna también.

Answer 2

Dudo que tal diferencia pueda relacionarse con el rendimiento en absoluto.
La mayoría de los problemas de rendimiento están relacionados con el diseño adecuado de la base de datos y el plan de indexación, y el ajuste del servidor/hardware como un nivel superior.

Answer 3

De acuerdo con los datos de MySQL storage su decimal requerirá

DECIMAL (10,0): 4 bytes para 9 dígitos y 1 byte para el día 10 dígitos restantes, lo que en total cinco bytes (suponiendo que mi lectura de la documentación es correcto).

INT (10): will need BIGINT que es de 8 bytes.

La diferencia es que el decimal está empaquetado y algunas operaciones en dicho tipo de datos pueden ser más lentas que en los tipos INT normales que se asignan directamente a los números representados en la máquina.

Todavía haría sus propias pruebas para confirmar el razonamiento anterior.

EDIT: Noté que no dio más detalles sobre el punto obvio - suponiendo la lógica anterior es sonar la diferencia en el tamaño requerido es 60% más de espacio necesario para la variante BIGINT.

Sin embargo, esto no se traduce directamente en penalizaciones debido a que los datos normalmente no se escriben byte por byte.En caso de selecciones/actualizaciones de muchas filas, debería ver la pérdida/ganancia de rendimiento, pero en caso de seleccionar/actualizar un número pequeño de filas, el sistema de archivos obtendrá bloques de los discos que normalmente obtendrán/escribirán múltiples columnas de todos modos .
El tamaño (y la velocidad) de los índices podría verse afectado más directamente. Sin embargo, la pregunta sobre cómo el empaque influye en varias operaciones aún permanece abierta.

Answer 4

De acuerdo con esta pregunta similar, sí, potencialmente hay una gran actuación golpeado debido a la diferencia en la forma en DECIMAL y INT se tratan y se ensarta en la CPU al hacer los cálculos.

Ver: Is there a performance hit using decimal data types (MySQL/Postgres)