Det kan bero på vilken version av MySQL du använder. Se här .
Före MySQL 5.0.3 lagrades DECIMAL-typen som en sträng och skulle vanligtvis vara långsammare. Men eftersom MySQL 5.0.3 DECIMAL-typen lagras i ett binärt format så med storleken på din DECIMAL ovan kanske det inte finns stor skillnad i prestanda.
Huvudproblemet med prestanda skulle ha varit hur mycket utrymme som togs upp av de olika typerna (där DECIMAL är långsammare). Med MySQL 5.0.3+ verkar detta vara ett mindre problem, men om du kommer att utföra numeriska beräkningar på värdena som en del av frågan kan det finnas en viss prestandaskillnad. Detta kan vara värt att testa eftersom det inte finns någon indikation i dokumentationen som jag kan se.
Redigera: När det gäller int(10) unsigned , jag tog detta till nominellt värde som bara en 4 byte int. Detta har dock ett maxvärde på 4294967295, vilket strikt sett inte ger samma nummerintervall som en DECIMAL(10,0) unsigned .
Som @Unreason påpekade, skulle du behöva använda en bigint för att täcka hela intervallet av 10-siffriga nummer, trycka storleken upp till 8 byte.
Ett vanligt misstag är att när man anger numeriska kolumntyper i MySQL, tror folk ofta att siffran inom parentes har en inverkan på storleken på numret de kan lagra. Det gör det inte. Nummerintervallet baseras enbart på kolumntypen och om den är signerad eller osignerad. Siffran inom parentes är för visningsändamål i resultat och har ingen inverkan på värdena som lagras i kolumnen. Det kommer inte heller att påverka visningen av resultaten om du inte anger ZEROFILL alternativ i kolumnen också.