Może to zależeć od używanej wersji MySQL. Zobacz tutaj .
Przed MySQL 5.0.3 typ DECIMAL był przechowywany jako ciąg i zwykle byłby wolniejszy. Jednak od MySQL 5.0.3 typ DECIMAL jest przechowywany w formacie binarnym, więc przy powyższym rozmiarze DECIMAL może nie być duża różnica w wydajności.
Głównym problemem z wydajnością byłaby ilość miejsca zajmowanego przez różne typy (przy czym DECIMAL jest wolniejszy). W przypadku MySQL 5.0.3+ wydaje się to być mniejszym problemem, jednak jeśli będziesz wykonywać obliczenia numeryczne na wartościach jako część zapytania, mogą wystąpić pewne różnice w wydajności. Może to być warte przetestowania, ponieważ w dokumentacji nie ma żadnych wskazówek, które widzę.
Edytuj: W odniesieniu do int(10) unsigned , wziąłem to według wartości nominalnej jako po prostu 4 bajty int. Jednak ma to maksymalną wartość 4294967295, która ściśle nie zapewnia tego samego zakresu liczb, co DECIMAL(10,0) unsigned .
Jak zauważył @Unreason, musisz użyć bigint aby objąć pełny zakres 10-cyfrowych liczb, zwiększając rozmiar do 8 bajtów.
Częstym błędem jest to, że określając typy kolumn numerycznych w MySQL, ludzie często myślą, że liczba w nawiasach ma wpływ na wielkość liczby, którą mogą przechowywać. Nie. Zakres numerów zależy wyłącznie od typu kolumny i tego, czy jest ze znakiem, czy bez znaku. Liczba w nawiasach służy do wyświetlania w wynikach i nie ma wpływu na wartości przechowywane w kolumnie. Nie będzie to również miało wpływu na wyświetlanie wyników, chyba że określisz ZEROFILL opcja również w kolumnie.
