Cela peut dépendre de la version de MySQL que vous utilisez. Voir ici .
Avant MySQL 5.0.3, le type DECIMAL était stocké sous forme de chaîne et était généralement plus lent. Cependant, depuis MySQL 5.0.3, le type DECIMAL est stocké dans un format binaire, donc avec la taille de votre DECIMAL ci-dessus, grande différence de performances.
Le principal problème de performances aurait été la quantité d'espace occupé par les différents types (avec DECIMAL étant plus lent). Avec MySQL 5.0.3+, cela semble être moins un problème, mais si vous effectuez des calculs numériques sur les valeurs dans le cadre de la requête, il peut y avoir une différence de performances. Cela peut valoir la peine d'être testé car il n'y a aucune indication dans la documentation que je peux voir.
Modifier : En ce qui concerne le int(10) unsigned , j'ai pris cela au pied de la lettre comme étant simplement un int de 4 octets. Cependant, cela a une valeur maximale de 4294967295 qui ne fournit strictement pas la même plage de nombres qu'un DECIMAL(10,0) unsigned .
Comme @Unreason l'a souligné, vous devrez utiliser un bigint pour couvrir toute la gamme des nombres à 10 chiffres, en poussant la taille jusqu'à 8 octets.
Une erreur courante est que lors de la spécification de types de colonnes numériques dans MySQL, les gens pensent souvent que le nombre entre parenthèses a un impact sur la taille du nombre qu'ils peuvent stocker. Ce n'est pas le cas. La plage de numéros est purement basée sur le type de colonne et si elle est signée ou non signée. Le nombre entre parenthèses est à des fins d'affichage dans les résultats et n'a aucun impact sur les valeurs stockées dans la colonne. Cela n'aura également aucun impact sur l'affichage des résultats sauf si vous spécifiez le ZEROFILL option sur la colonne également.
