Puede depender de la versión de MySQL que esté utilizando. Ver aquí .
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 formato binario, por lo que con el tamaño de su DECIMAL anterior, es posible 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 (siendo DECIMAL más lento). Con MySQL 5.0.3+, esto parece ser un problema menor, sin embargo, si va a realizar cálculos numéricos en los valores como parte de la consulta, puede haber alguna diferencia de rendimiento. Puede valer la pena probar esto ya que no hay ninguna indicación en la documentación que pueda ver.
Editar: Con respecto al int(10) unsigned , tomé esto al pie de la letra como un int de 4 bytes. Sin embargo, esto tiene un valor máximo de 4294967295 que estrictamente no proporciona el mismo rango de números que un DECIMAL(10,0) unsigned sin firmar .
Como señaló @Unreason, necesitaría usar un bigint para cubrir el rango completo de números de 10 dígitos, elevando el tamaño hasta 8 bytes.
Un error común es que cuando se especifican tipos de columnas numéricas en MySQL, las personas a menudo piensan que el número entre paréntesis tiene un impacto en el tamaño del número que pueden almacenar. no lo hace El rango de números se basa únicamente en el tipo de columna y si está firmada o no. El número entre paréntesis se muestra en los resultados y no afecta a los valores almacenados en la columna. Tampoco tendrá impacto en la visualización de los resultados a menos que especifique el ZEROFILL opción en la columna también.
