Det kan afhænge af den version af MySQL du bruger. Se her .
Før MySQL 5.0.3 blev DECIMAL-typen gemt som en streng og ville typisk være langsommere. Da MySQL 5.0.3 dog DECIMAL-typen er gemt i et binært format, så med størrelsen på din DECIMAL ovenfor, er der muligvis ikke stor forskel i ydeevne.
Det vigtigste præstationsproblem ville have været mængden af plads, som de forskellige typer optager (hvor DECIMAL er langsommere). Med MySQL 5.0.3+ ser dette ud til at være et mindre problem, men hvis du skal udføre numeriske beregninger på værdierne som en del af forespørgslen, kan der være en vis ydeevneforskel. Dette kan være værd at teste, da der ikke er nogen indikation i dokumentationen, som jeg kan se.
Rediger: Med hensyn til int(10) unsigned , jeg tog dette for pålydende værdi som blot værende en 4 byte int. Dette har dog en maksimal værdi på 4294967295, hvilket strengt taget ikke giver det samme talinterval som en DECIMAL(10,0) unsigned .
Som @Unreason påpegede, skal du bruge en bigint for at dække hele rækken af 10-cifrede tal og skubbe størrelsen op til 8 bytes.
En almindelig fejl er, at når de angiver numeriske kolonnetyper i MySQL, tror folk ofte, at tallet i parentes har en indflydelse på størrelsen af det tal, de kan gemme. Det gør den ikke. Nummerområdet er udelukkende baseret på kolonnetypen og om den er signeret eller usigneret. Tallet i parentes er til visningsformål i resultater og har ingen indflydelse på de værdier, der er gemt i kolonnen. Det vil heller ikke have nogen indflydelse på visningen af resultaterne, medmindre du angiver ZEROFILL mulighed også i kolonnen.