Het kan afhangen van de versie van MySQL die u gebruikt. Zie hier .
Vóór MySQL 5.0.3 werd het DECIMAL-type opgeslagen als een tekenreeks en zou dit doorgaans langzamer zijn. Sinds MySQL 5.0.3 wordt het DECIMAL-type echter opgeslagen in een binair formaat, dus met de grootte van uw DECIMAL hierboven is er mogelijk geen veel verschil in prestaties.
Het belangrijkste prestatieprobleem zou de hoeveelheid ruimte zijn geweest die door de verschillende typen wordt ingenomen (waarbij DECIMAL langzamer is). Met MySQL 5.0.3+ lijkt dit minder een probleem te zijn, maar als u numerieke berekeningen op de waarden uitvoert als onderdeel van de query, kan er een prestatieverschil zijn. Dit kan het testen waard zijn, aangezien er geen indicatie in de documentatie is die ik kan zien.
Bewerken: Met betrekking tot de int(10) unsigned , nam ik dit op het eerste gezicht als een 4 byte int. Dit heeft echter een maximale waarde van 4294967295, wat strikt genomen niet hetzelfde bereik van getallen biedt als een DECIMAL(10,0) unsigned .
Zoals @Unreason al aangaf, zou je een bigint . moeten gebruiken om het volledige bereik van 10-cijferige nummers te dekken, met een maximale grootte van 8 bytes.
Een veelgemaakte fout is dat mensen bij het specificeren van typen numerieke kolommen in MySQL vaak denken dat het getal tussen de haakjes invloed heeft op de grootte van het nummer dat ze kunnen opslaan. Dat doet het niet. Het nummerbereik is puur gebaseerd op het kolomtype en of het al dan niet ondertekend is. Het getal tussen haakjes is voor weergavedoeleinden in resultaten en heeft geen invloed op de waarden die in de kolom zijn opgeslagen. Het heeft ook geen invloed op de weergave van de resultaten, tenzij u de ZEROFILL . opgeeft optie ook in de kolom.