Dies kann von der verwendeten MySQL-Version abhängen. Siehe hier .
Vor MySQL 5.0.3 wurde der DECIMAL-Typ als String gespeichert und war normalerweise langsamer. Seit MySQL 5.0.3 wird der DECIMAL-Typ jedoch in einem Binärformat gespeichert, sodass die Größe Ihres DECIMAL oben möglicherweise nicht vorhanden ist großer Leistungsunterschied.
Das Hauptleistungsproblem wäre die Menge an Speicherplatz gewesen, die von den verschiedenen Typen eingenommen wird (wobei DECIMAL langsamer ist). Mit MySQL 5.0.3+ scheint dies weniger ein Problem zu sein, wenn Sie jedoch numerische Berechnungen mit den Werten als Teil der Abfrage durchführen, kann es zu Leistungsunterschieden kommen. Dies kann einen Test wert sein, da es keinen Hinweis in der Dokumentation gibt, den ich sehen kann.
Bearbeiten: In Bezug auf int(10) unsigned , ich habe dies für bare Münze genommen, da es sich nur um ein 4-Byte-Int handelt. Dies hat jedoch einen maximalen Wert von 4294967295, der streng genommen nicht den gleichen Zahlenbereich wie ein DECIMAL(10,0) unsigned bietet .
Wie @Unreason betonte, müssten Sie einen bigint verwenden um den gesamten Bereich der 10-stelligen Zahlen abzudecken und die Größe auf 8 Byte zu erhöhen.
Ein häufiger Fehler ist, dass bei der Angabe numerischer Spaltentypen in MySQL oft angenommen wird, dass die Zahl in den Klammern einen Einfluss auf die Größe der Zahl hat, die sie speichern können. Das tut es nicht. Der Nummernkreis richtet sich rein nach dem Spaltentyp und ob diese vorzeichenbehaftet oder vorzeichenlos ist. Die Zahl in Klammern dient der Anzeige in Ergebnissen und hat keinen Einfluss auf die in der Spalte gespeicherten Werte. Es hat auch keinen Einfluss auf die Anzeige der Ergebnisse, es sei denn, Sie geben ZEROFILL an Option auch in der Spalte.
