Може да зависи от версията на MySQL, която използвате. Вижте тук .
Преди MySQL 5.0.3 типът DECIMAL се съхраняваше като низ и обикновено би бил по-бавен. Въпреки това, тъй като MySQL 5.0.3 типът DECIMAL се съхранява в двоичен формат, така че с размера на вашия DECIMAL по-горе, може да няма голяма разлика в производителността.
Основният проблем с производителността би бил количеството пространство, заето от различните типове (като DECIMAL е по-бавен). С MySQL 5.0.3+ това изглежда по-малко проблем, но ако ще извършвате числови изчисления на стойностите като част от заявката, може да има известна разлика в производителността. Това може да си струва да се тества, тъй като в документацията няма индикация, която мога да видя.
Редактиране: По отношение на int(10) unsigned , взех това по номинална стойност като просто 4 байтово int. Това обаче има максимална стойност от 4294967295, която строго не предоставя същия диапазон от числа като DECIMAL(10,0) unsigned .
Както @Unreason посочи, ще трябва да използвате bigint за да покриете пълния диапазон от 10-цифрени числа, като увеличите размера до 8 байта.
Често срещана грешка е, че когато определят типовете числови колони в MySQL, хората често смятат, че числото в скобите оказва влияние върху размера на числото, което могат да съхраняват. Не е така. Диапазонът от числа се основава изцяло на типа колона и дали е със знак или без знак. Числото в скобите е за целите на показване в резултатите и не оказва влияние върху стойностите, съхранени в колоната. Освен това няма да окаже влияние върху показването на резултатите, освен ако не посочите ZEROFILL опция и в колоната.
