it-swarm-eu.dev

Wann sollte TINYINT über INT verwendet werden?

Im Allgemeinen verwende ich immer Ints. Ich weiß, dass dies theoretisch nicht die beste Vorgehensweise ist, da Sie sollten den kleinsten Datentyp verwenden, der garantiert die Daten speichert.

Zum Beispiel ist es besser, tinyint zu verwenden, wenn Sie wissen, dass die einzigen Daten, die Sie speichern, eine 1, 0 oder null sind (mit einer sehr geringen Wahrscheinlichkeit, diese später auf 2 oder 3 zu erweitern).

Der einzige Grund, den ich dafür kenne, ist die Speicherung - 1 Byte in einer Zeile anstelle von 4 Byte.

Welche Auswirkungen hat die Verwendung von tinyint (oder smallint oder sogar bigint) auf nur int, abgesehen von der Speicherplatzersparnis auf Ihrer Festplatte?

92
Richard

Speicherplatz ist billig ... das ist nicht der Punkt!

Denken Sie nicht mehr an Speicherplatz, sondern an Pufferpool und Speicherbandbreite . Am äußersten Ende CPU-Cache und Speicherbusbandbreite . Der verlinkte Artikel ist Teil der Reihe, in der Probleme mit einer schlechten Auswahl von Clusterschlüsseln hervorgehoben werden (INT vs GUID vs Sequential GUID), aber er zeigt den Unterschied auf, den Bytes bewirken können.

Die übergeordnete Botschaft ist Design. Der Unterschied wird erst in einer einzelnen Datenbank auf einem entsprechend spezifizierten Server angezeigt, wenn Sie das VLDB-Gebiet erreicht haben. Wenn Sie jedoch einige Bytes speichern können, warum nicht?.

Ich erinnere mich an die Umgebung, die in einem frühere Frage beschrieben ist. Über 400 Datenbanken mit einer Größe von 50 MB bis 50 GB pro SQL-Instanz. Das Scrubben einiger Bytes pro Datensatz, pro Tabelle und pro Datenbank in dieser Umgebung kann einen signifikanten Unterschied bewirken.

92

Neben den anderen Antworten ...

Zeilen und Indexeinträge werden auf 8.000 Seiten gespeichert. Eine Million Zeilen mit 3 Bytes pro Zeile sind also nicht 3 MB auf der Festplatte. Dies wirkt sich auf die Anzahl der Zeilen pro Seite aus ("Seitendichte").

Gleiches gilt für nvarchar zu varchar, smalldatetime zu datetime, int zu tinyint usw.

Bearbeiten, Juni 2013

http://sqlblog.com/blogs/joe_chang/archive/2013/06/16/load-test-manifesto.aspx

Dieser Artikel besagt

Die wichtigen Kriterien sind die Kardinalität und das Verhältnis von Seite zu Zeile.

Die Wahl des Datentyps spielt also eine Rolle

29
gbn

Dabei geht es nicht nur um die Speicherung von Tabellen. Wenn Sie Indizes verwenden, bei denen die int-Spalte Teil eines zusammengesetzten Schlüssels ist, möchten Sie natürlich, dass die Indexseiten so voll wie möglich sind. Dies ist das Ergebnis von Indexeinträgen, die so klein wie möglich sind.

Ich würde definitiv erwarten, dass die Prüfung von Indexeinträgen auf BTREE-Seiten bei kleineren Datentypen etwas schneller ist. Alle an Indexeinträgen beteiligten VARCHARs würden jedoch Leistungsgewinne aus der Verwendung von TINYINT über INT ausgleichen (aufheben).

Ungeachtet dessen ist es umso besser und schneller, wenn Indexeinträge zusammengesetzte Einträge haben und alle Ganzzahlen sind, je kleiner die Ganzzahlen byteweise sind.

14
RolandoMySQLDBA

Alle Dinge werden komplexer, wenn Datenbanken größer werden:

  • wartungsfenster müssen vergrößert oder verschoben werden
  • backups (das vollständige Backup am Ende des Tages wird zu einem absurden Zeitfresser, daher benötigen Sie ein Differential oder protokollieren sogar Backups und führen das vollständige einmal pro Woche, möglicherweise einmal im Monat durch.)
  • leistungswartungen werden zu einem Zeitfresser (das Erstellen eines Index für eine Tabelle mit mehreren Millionen Zeilen benötigt keine triviale Zeit für die Ausführung) und muss neu geplant werden und wird schlechter, wenn die Tabelle breit ist ...
  • Und das Übertragen dieses 100-Gbit-Backups über das Netzwerk ist kein Kinderspiel - besonders wenn das Netzwerk (aus einem unbekannten Grund) hartnäckig ist, wenn die Verbindung auf die 75-Gbit-Marke getrennt wird ... (geschah mit einer Installation, an der ich gearbeitet habe wurde auf ein zugeordnetes Laufwerk im Netzwerk gesichert - Netzwerk) ...

Und welche Datentypen haben damit zu tun? ALLES. Wenn Sie Zeilengrößen verwenden, die größer als erforderlich sind, werden die Datenbankseiten früher als erforderlich gefüllt oder es wird sogar Speicherplatz verschwendet, wenn die Zeilengröße so ist dass nicht mehr als ein Datensatz auf der Seite aufgezeichnet werden kann. Das Ergebnis ist, dass mehr Seiten zum Schreiben und Lesen benötigt werden, mehr RAM Speicher wird verwendet, um dies zwischenzuspeichern (größere Datensätze benötigen größeren Speicher). Und da Ihre Datentypen größer angegeben werden als von der Festplatte benötigt, sind Ihre Indizes Das gleiche Problem tritt auf - insbesondere, wenn Sie diesen zusammengesetzten Primärschlüssel mit 2 BIGINT-Spalten gruppieren, da alle anderen erstellten Indizes diesen Primärschlüssel implizit in ihre Definition kopieren.

Wenn Sie wissen, dass einige Spalten in einer Tabelle Millionen von Zeilen enthalten, oder sogar eine kleine Tabelle, die mehrere Millionen Zeilen enthält, die keine 4-Byte-Ganzzahl zum Speichern ihrer Daten benötigen, sondern eine 2-Byte-Ganzzahl genügen - benutze SMALLINT . Wenn Werte im Bereich von 0 bis 255 ausreichen, TINYINT . Eine Ja/Nein-Flagge? Es gibt BIT .

13
Fabricio Araujo

Während es für tinyint vs int deutliche Unterschiede wie Speicherplatz, Seitenteilung und Wartungszeit gibt, würde es für varchar keine geben.

Warum also nicht alle Textfelder als varchar(4000) deklarieren, da dadurch ohnehin nur der benötigte Platz belegt wird? Darüber hinaus wird Ihnen garantiert, dass Ihre Daten niemals abgeschnitten werden.

Die Antwort lautet natürlich:

  1. Klarstellung Ihrer Absichten (da niemand verstehen wird, warum ein Namensfeld 4000 Zeichen umfassen sollte)
  2. Validierung, um sicherzustellen, dass niemand eine vollständige Biografie als Namen eingibt.

Dieselben Gründe gelten auch für tinyint.

9
yoel halb