it-swarm.com.de

SQL SELECT Geschwindigkeit int vs varchar

Ich bin gerade dabei, einen Tisch zu erstellen, und das hat mich gewundert.

Wenn ich speichere, sagen Sie Autos, die eine Marke haben (zB BMW, Audi ect.), Wird sich dies auf die Abfragegeschwindigkeit auswirken, wenn ich die Marke als Int oder Varchar abspeichere.

So ist es

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

Schneller/langsamer als

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

oder ist die Geschwindigkeit mehr oder weniger gleich?

87
googletorp

Int-Vergleiche sind schneller als Varchar-Vergleiche, da ints wesentlich weniger Platz als Varchars beansprucht.

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


Wie Sie sehen, haben Sie die Frage postgreql mit einem Tag versehen. Möglicherweise interessieren Sie sich für die Speicherplatznutzung verschiedener Datumstypen:

84
Robert Munteanu

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 für 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 aussieht, für diesen Aufbau, solange Ihre Indexe in den RAM-Speicher passen, macht bigint vs 16-Char Text keinen Unterschied in der Geschwindigkeit.

19

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

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

16
Guffa

Auf die tatsächliche Leistung des Zeichenkettenvergleichs im Vergleich zu Nicht-Floaten ist in diesem Fall jede Größe ohne Vorzeichen und Vorzeichen ohne Bedeutung. Größe ist eigentlich der wahre Unterschied in der Leistung. Sei es 1Byte + (bis zu 126Byte) im Vergleich zu 1,2,4 oder 8Byte-Vergleich ... Offensichtlich sind Nicht-Float-Werte kleiner als Strings und Floats und daher in der Assembly CPU-freundlicher.

Der String-zu-String-Vergleich in all languages ​​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 höher. * Sehen Sie sich die produzierte Assembly (selbst von Hand) erneut an, um mehr char-Zeichen zu vergleichen als 1 bis 8-Byte-CPU-Zahlen.

Nun, wie viel schneller? hängt auch von der Datenmenge 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. Je nach CPU, Implementierung (Client/Server, Web/Skript usw.) werden Sie dies wahrscheinlich erst sehen, wenn Sie einige Hundert Vergleiche auf dem DB-Server durchlaufen haben (vielleicht sogar einige tausend Vergleiche, bevor es auffällt).

  • Den falschen Streit über Hashvergleiche aufheben. Die meisten Hash-Algorithmen selbst sind langsam, so dass Sie nicht von CRC64 und kleineren Dingen profitieren. Seit über 12 Jahren entwickelte ich Suchalgorithmen für Suchmaschinen mit mehreren Bundesländern und 7 Jahre für Kreditbüros. Alles, was Sie in numerischer Form behalten können, ist schneller. Beispielsweise sind Telefonnummern, Postleitzahlen und sogar Währungen * 1000 (Speicherwährung) div 1000 (Abruf) schneller als DECIMAL für Vergleiche.

Ozz 

6
Ozz Nixon

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

4
anthares

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 den Int. Bei größeren Tabellen bedeutet dies möglicherweise Hunderte von Megabytes (und Tausende von Seiten). Dadurch wird die Leistung erheblich schlechter, da das Lesen des Index allein viele Plattenlesevorgänge erfordert.

4
Konrad Garus

Hinweis: Wenn sich die möglichen Werte für das Feld make _ ​​nie (oder selten) ändern, können Sie ENUM als Kompromiss verwenden. Es kombiniert eine gute Geschwindigkeit mit einer guten Lesbarkeit.

3
Thomas Schaub

Wenn Sie Indizierung eines der Felder aktivieren, wird es schneller sein. Was Ihre Frage betrifft, denke ich, dass int schneller ist als varchar.

1
Sarfraz

Etwas relativ. Ja, INTs werden schneller sein, aber die Frage ist, ob es in Ihrer Situation wahrnehmbar ist. Sind die VARCHARs nur kleine Wörter oder längere Texte? und wie viele Zeilen sind in der Tabelle? Wenn nur ein paar Zeilen vorhanden sind, wird dies höchstwahrscheinlich vollständig im Speicher zwischengespeichert (wenn häufig angefordert). In diesem Fall werden Sie keinen großen Unterschied feststellen. Dann gibt es natürlich eine Indexierung, die umso wichtiger wird, wenn der Tisch wächst. Die Verwendung von SSDs ist möglicherweise schneller als die von HD mit optimierten Abfragen. Auch gute Festplatten-Controller beschleunigen manchmal Abfragen> 10x. Dies lässt möglicherweise nur Raum für die Verwendung von VARCHARs, was das Lesen und Schreiben von Abfragen vereinfacht (keine Notwendigkeit, komplexe Joins zu schreiben) und die Entwicklung zu beschleunigen. Puristen werden jedoch alles widersprechen und immer normalisieren. 

0
Alex