SQL SELECT Geschwindigkeit int vs varchar

Ich bin gerade dabei, eine Tabelle zu erstellen, und ich habe mich gefragt.

Wenn ich Autos mit einer Marke speichere (z. B. BMW, Audi usw.), hat dies einen Einfluss auf die Abfragegeschwindigkeit, wenn ich die Marke als int oder varchar speichere.

So ist es auch

SELECT * FROM table WHERE make = 5 AND ...;

Schneller / langsamer als

SELECT * FROM table WHERE make = 'audi' AND ...;

oder wird die Geschwindigkeit mehr oder weniger gleich sein?

Int-Vergleiche sind schneller als Varchar-Vergleiche, da Ints viel weniger Platz beanspruchen als Varchars.

Dies gilt sowohl für nicht indizierten als auch für indizierten Zugriff. Der schnellste Weg ist eine indizierte int-Spalte.

Wie ich sehe, haben Sie die Frage postgreql markiert. Möglicherweise interessieren Sie sich für die Speicherplatznutzung verschiedener Datumstypen:

• intFelder belegen zwischen 2 und 8 Bytes , wobei 4 normalerweise mehr als ausreichend sind (-2147483648 bis +2147483647).
• Zeichentypen belegen 4 Bytes plus die tatsächlichen Zeichenfolgen .

Einige grobe Benchmarks:

4 Millionen Datensätze in Postgres 9.x.

Table A = base table with some columns
Table B = Table A + extra column id of type bigint with random numbers
Table C = Table A + extra column id of type text with random 16-char ASCII strings

Ergebnisse auf 8 GB RAM, i7, SSD-Laptop:

Size on disk:                A=261MB        B=292MB        C=322MB
Non-indexed by id: select count(*), select by id: 450ms same on all tables
Insert* one row per TX:       B=9ms/record        C=9ms/record
Bulk insert* in single TX:    B=140usec/record    C=180usec/record
Indexed by id, select by id:  B=about 200us       C=about 200us

* inserts to the table already containing 4M records

So wie es für dieses Setup aussieht, macht Bigint im Vergleich zu 16-stelligem Text keinen Unterschied in der Geschwindigkeit, solange Ihre Indizes in den Arbeitsspeicher passen.

Mit einem int anstelle eines varchar wird es etwas schneller. Wichtiger für die Geschwindigkeit ist es, einen Index für das Feld zu haben, mit dem die Abfrage die Datensätze finden kann.

Es gibt einen weiteren Grund, ein int zu verwenden, nämlich die Datenbank zu normalisieren. Anstatt den Text 'Mercedes-Benz' tausende Male in der Tabelle zu speichern, sollten Sie seine ID speichern und den Markennamen einmal in einer separaten Tabelle speichern.

In diesem Fall spielt es keine Rolle, ob die Größe des Zeichenfolgenvergleichs im Vergleich zu Nicht-Floats vorliegt oder nicht. Größe ist eigentlich der wahre Leistungsunterschied. Sei es 1 Byte + (bis zu 126 Byte) im Vergleich zu 1,2,4 oder 8 Byte Vergleich ... offensichtlich sind Nicht-Float kleiner als Strings und Floats und daher CPU-freundlicher in der Montage.

Der Vergleich von Zeichenfolgen zu Zeichenfolgen in allen Sprachen ist langsamer als etwas, das von der CPU in einem Befehl verglichen werden kann. Selbst der Vergleich von 8 Byte (64 Bit) auf einer 32-Bit-CPU ist immer noch schneller als ein VARCHAR (2) oder größer. * Schauen Sie sich noch einmal die produzierte Baugruppe an (auch von Hand). Es sind mehr Anweisungen erforderlich, um char by char zu vergleichen, als 1 bis 8 Byte CPU-Zahlen.

Wie viel schneller? hängt auch vom Datenvolumen ab. Wenn Sie einfach 5 mit 'audi' vergleichen - und das ist alles, was Ihre Datenbank hat, ist der resultierende Unterschied so gering, dass Sie ihn niemals sehen würden. Abhängig von der CPU, der Implementierung (Client / Server, Web / Skript usw.) wird es wahrscheinlich erst angezeigt, wenn Sie einige hundert Vergleiche auf dem DB-Server durchgeführt haben (möglicherweise sogar ein paar tausend Vergleiche, bevor es auffällt).

• Um den falschen Streit über Hash-Vergleiche aufzuheben. Die meisten Hashing-Algorithmen selbst sind langsam, sodass Sie nicht von Dingen wie CRC64 und kleiner profitieren. Über 12 Jahre lang habe ich Suchalgorithmen für Suchmaschinen mit mehreren Landkreisen und 7 Jahre für die Kreditauskunfteien entwickelt. Alles, was Sie numerisch halten können, ist schneller ... zum Beispiel Telefonnummern, Postleitzahlen, sogar Währung * 1000 (Speicher) Währung div 1000 (Abruf) ist für Vergleiche schneller als DECIMAL.

Ozz

Index oder nicht, int ist viel schneller (je länger der Varchar, desto langsamer wird er).

Ein weiterer Grund: Der Index für das Varchar-Feld ist viel größer als für Int. Bei größeren Tabellen kann dies Hunderte von Megabyte (und Tausende von Seiten) bedeuten. Dies macht die Leistung erheblich schlechter, da das Lesen des Index allein viele Festplattenlesevorgänge erfordert.

Im Allgemeinen wird der int schneller sein. Je länger der Varchar ist, desto langsamer wird er

Hinweis: Wenn die möglichen Werte für das Feld machen werden nie (oder selten) ändern, Sie ENUM als Kompromiss verwenden können. Es kombiniert gute Geschwindigkeit mit guter Lesbarkeit.

Wenn Sie die Indizierung für eines der Felder aktivieren, ist dies schneller. Was deine Frage betrifft, denke ich intist schneller als varchar.

Etwas relativ. Ja, INTs werden schneller sein, aber die Frage ist, ob es in Ihrer Situation auffällt. Sind die VARCHARs nur ein paar kleine Wörter oder längere Texte? und wie viele Zeilen enthält die Tabelle? Wenn es nur wenige Zeilen gibt, wird es höchstwahrscheinlich vollständig im Speicher gepuffert (wenn dies häufig angefordert wird). In diesem Fall werden Sie keinen großen Unterschied bemerken. Dann gibt es natürlich eine Indizierung, die wichtiger wird, wenn die Tabelle wächst. Die Verwendung von SSDs ist möglicherweise schneller als HDs mit optimierten Abfragen. Auch gute Festplattencontroller beschleunigen manchmal Abfragen> 10x. Dies lässt möglicherweise Platz für die Verwendung von VARCHARs, was das Lesen und Schreiben von Abfragen erleichtert (es müssen keine komplexen Verknüpfungen geschrieben werden) und die Entwicklung beschleunigt. Puristen werden jedoch nicht zustimmen und immer alles normalisieren.