SQL SELECT speed int vs varchar

Question

Je suis en train de créer une table et ça m'a fait réfléchir.

Si je stocke, disons les voitures qui ont une marque (fx BMW, Audi ect.), cela fera une différence sur la vitesse de la requête si je stocke la marque comme un int ou un varchar.

Il en est de même

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

Plus rapide/plus lent que

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

ou la vitesse sera-t-elle plus ou moins la même ?

Answer 1

Quelques repères approximatifs :

4 millions d'enregistrements dans 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

Résultats sur un ordinateur portable SSD, i7, 8 Go de RAM :

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

Il semble donc que pour cette configuration, tant que vos index s'adaptent à la RAM, bigint vs texte à 16 caractères ne fait aucune différence de vitesse.

Answer 2

Il sera un peu plus rapide d'utiliser un int au lieu d'un varchar. Plus important pour la vitesse est d'avoir un index sur le champ que la requête peut utiliser pour trouver les enregistrements.

Il y a une autre raison d'utiliser un int, c'est de normaliser la base de données. Au lieu d'avoir le texte 'Mercedes-Benz' stocké des milliers de fois dans le tableau, vous devriez stocker son id et avoir le nom de la marque stocké une fois dans un tableau séparé.

Answer 3

Index ou non, int est beaucoup plus rapide (plus le varchar est long, plus il est lent).

Une autre raison : l'index sur le champ varchar sera beaucoup plus grand que sur int. Pour les tables plus grandes, cela peut signifier des centaines de mégaoctets (et des milliers de pages). Cela rend la performance bien pire que la lecture de l'index seul nécessite de nombreuses lectures de disque.