Dezimal VS Int in MySQL?

Question

Gibt es einen Leistungsunterschied zwischen decimal(10,0) unsigned Typ und int(10) unsigned Typ?

Answer 1

Es hängt möglicherweise von der Version von MySQL ab, die Sie verwenden. Siehe here.

Vor MySQL 5.0.3 wurde der DECIMAL-Typ als String gespeichert und in der Regel langsamer sein würde. Da jedoch seit MySQL 5.0.3 der DECIMAL-Typ in einem binären Format gespeichert ist, ist die Leistung Ihres DECIMAL möglicherweise nicht sehr unterschiedlich.

Das Hauptleistungsproblem des Platzes durch die verschiedenen Arten aufgenommen (mit DECIMAL langsamer ist) gewesen wäre. Mit MySQL 5.0.3+ scheint dies weniger ein Problem zu sein. Wenn Sie jedoch numerische Berechnungen für die Werte als Teil der Abfrage ausführen, kann es zu Leistungseinbußen kommen. Dies kann sich lohnen, da es in der Dokumentation keine Hinweise gibt, die ich sehen kann.

Edit: In Bezug auf die int(10) unsigned, ich nahm dies zum Nennwert als nur ein 4-Byte-int zu sein. Dies hat jedoch einen maximalen Wert von 4294967295, der streng genommen nicht den gleichen Zahlenbereich wie DECIMAL(10,0) unsigned bietet.

Wie @Unreason darauf hingewiesen hat, müssten Sie einen bigint verwenden, um den vollen Bereich der 10-stelligen Zahlen abzudecken, was die Größe auf bis zu 8 Bytes erhöht.

Ein häufiger Fehler ist, dass, wenn numerische Spalten Typen in MySQL spezifizieren, denken die Leute oft die Zahl in den Klammern einen Einfluss auf die Größe der Zahl hat sie speichern können. Es tut es nicht. Der Nummernkreis basiert ausschließlich auf dem Spaltentyp und darauf, ob er signiert oder unsigniert ist. Die Zahl in den Klammern dient zur 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 auch die ZEROFILL Option für die Spalte an.

Answer 2

Ich bezweifle, dass ein solcher Unterschied überhaupt leistungsbezogen sein kann.
Die meisten Leistungsprobleme sind mit dem ordnungsgemäßen Datenbankentwurf und dem Planungsplan sowie dem Server-/Hardware-Tuning als nächste Ebene verbunden.

Answer 3

Nach den MySQL-Daten storage Ihre dezimal wird

DECIMAL (10,0) erfordern: 4 Byte für 9 Ziffern und 1 Byte für die restlichen 10. Stelle, also insgesamt fünf Bytes (meiner Lektüre der Dokumentation unter der Annahme, ist richtig).

INT (10): will need BIGINT die 8 Bytes ist.

Die Unterschiede bestehen darin, dass die Dezimalstelle gepackt und einige Operationen auf solchen Datentyp können auf normalen INT-Typen langsamer dann sein, die direkt abbilden zu Maschinenzahlen dargestellt.

Noch würde ich Ihre eigenen Tests machen, um die obigen Überlegungen zu bestätigen.

EDIT: Ich bemerkte, dass ich nicht auf dem offensichtlichen Punkt auszuarbeiten habe - die obige Logik unter der Annahme, klingen die Differenz erforderlich in Größe 60% mehr Platz für BIGINT Variante benötigt wird.

Allerdings bedeutet dies übersetzt nicht direkt an Strafen aufgrund der Tatsache, dass die Daten in der Regel nicht Byte für Byte geschrieben.Im Falle von Auswahlen/Aktualisierungen von vielen Zeilen sollte der Leistungsverlust/Gewinn zu sehen sein, aber im Falle der Auswahl/Aktualisierung einer kleinen Anzahl von Zeilen wird das Dateisystem Blöcke von den Platten holen, die normalerweise mehrere Spalten erhalten/schreiben .
Die Größe (und Geschwindigkeit) von Indizes ist möglicherweise direkter betroffen. Die Frage, wie die Verpackung verschiedene Operationen beeinflusst, bleibt jedoch offen.

Answer 4

Nach dieser ähnlichen Frage, ja, möglicherweise gibt es eine große Leistung Hit wegen Unterschied in der Art und Weise DECIMAL und INT behandelt werden und in die CPU Gewinde wenn Berechnungen zu tun.

See: Is there a performance hit using decimal data types (MySQL/Postgres)