Může to záviset na verzi MySQL, kterou používáte. Viz zde .
Před MySQL 5.0.3 byl typ DECIMAL uložen jako řetězec a byl obvykle pomalejší. Od verze MySQL 5.0.3 je však typ DECIMAL uložen v binárním formátu, takže s velikostí vašeho DECIMAL výše nemusí být velký rozdíl ve výkonu.
Hlavním problémem s výkonem by bylo množství místa, které zabírají různé typy (přičemž DECIMAL je pomalejší). S MySQL 5.0.3+ to vypadá jako menší problém, ale pokud budete provádět numerické výpočty hodnot jako součást dotazu, může dojít k určitému rozdílu ve výkonu. To může stát za otestování, protože v dokumentaci není žádný náznak, že bych to viděl.
Upravit: S ohledem na int(10) unsigned , vzal jsem to v nominální hodnotě jen jako 4bajtový int. Toto má však maximální hodnotu 4294967295, což striktně neposkytuje stejný rozsah čísel jako DECIMAL(10,0) unsigned .
Jak zdůraznil @Unreason, budete muset použít bigint aby pokryl celý rozsah 10ciferných čísel, velikost se posunula až na 8 bajtů.
Častou chybou je, že při zadávání typů číselných sloupců v MySQL si lidé často myslí, že číslo v závorce má vliv na velikost čísla, které mohou uložit. To ne. Rozsah čísel je čistě založen na typu sloupce a na tom, zda je podepsaný nebo nepodepsaný. Číslo v závorce slouží pro účely zobrazení ve výsledcích a nemá žádný vliv na hodnoty uložené ve sloupci. Pokud nezadáte ZEROFILL, nebude to mít žádný vliv na zobrazení výsledků možnost také na sloupci.