Je suis en train de créer une table et cela m'a fait me demander.
Si je stocke, disons des voitures qui ont une marque (fx BMW, Audi ect.), Cela fera-t-il une différence sur la vitesse de requête si je stocke la marque comme int ou varchar.
Ainsi est
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?
Réponses:
Les comparaisons int sont plus rapides que les comparaisons varchar, pour le simple fait que les ints prennent beaucoup moins d'espace que les varchars.
Cela est vrai à la fois pour les accès non indexés et indexés. Le moyen le plus rapide est d'utiliser une colonne int indexée.
Comme je vois que vous avez tagué la question postgreql, vous pourriez être intéressé par l'utilisation de l'espace de différents types de date:
intles champs occupent entre 2 et 8 octets , 4 étant généralement plus que suffisants (-2147483648 à +2147483647)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 stringsRésultats sur 8 Go de RAM, i7, ordinateur portable SSD:
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 recordsil semble donc que pour cette configuration, tant que vos index tiennent dans la RAM, le texte bigint vs 16 caractères ne fait aucune différence en termes de vitesse.
Ce sera un peu plus rapide en utilisant un int au lieu d'un varchar. Le 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, et 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 devez stocker son identifiant et stocker le nom de la marque une fois dans une table séparée.
Mercedes-Benzstocker des milliers de fois id 1. Par exemple, table car_brands, colonnes Brandset Id. Row Mercedes-Benzet 1. Et dans la colonne Brandset la valeur de la table principale 1. Et quand SELECT, alors d'abord, sortez Idde la table car_brandset ensuite SELECT Something FROM main_table WHERE Brands = (SELECT Id FROM car_brands WHERE Brands = Mercedes-Benz). Ou une autre approche?
select something from main_table c inner join car_brands b on b.Id = c.Brands where b.Brands = 'Mercedes-Benz'.
Pour résumer les performances réelles de la comparaison de chaînes par rapport aux non-flottants, dans ce cas, toute taille non signée et signée n'a pas d'importance. La taille est en fait la vraie différence de performance. Que ce soit 1 octet + (jusqu'à 126 octets) contre 1,2,4 ou 8 octets de comparaison ... évidemment, les non-float sont plus petits que les chaînes et les flottants, et donc plus conviviaux pour le processeur en assemblage.
La comparaison de chaîne à chaîne dans toutes les langues est plus lente que quelque chose qui peut être comparé en une instruction par le processeur. Même comparer 8 octets (64 bits) sur un processeur 32 bits est toujours plus rapide qu'un VARCHAR (2) ou plus. * Encore une fois, regardez l'assemblage produit (même à la main), il faut plus d'instructions pour comparer char par char que 1 à 8 octets CPU numérique.
Maintenant, combien plus vite? dépend également du volume de données. Si vous comparez simplement 5 à «audi» - et c'est tout ce que votre DB a, la différence qui en résulte est si minime que vous ne la verrez jamais. En fonction du processeur, de la mise en œuvre (client / serveur, Web / script, etc.), vous ne le verrez probablement pas tant que vous n'aurez pas atteint quelques centaines de comparaisons sur le serveur de base de données (peut-être même quelques milliers de comparaisons avant que cela ne soit perceptible).
Ozz
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 des tableaux plus volumineux, cela peut signifier des centaines de mégaoctets (et des milliers de pages). Cela rend les performances bien pires car la lecture de l'index seul nécessite de nombreuses lectures de disque.
Astuce: si les valeurs possibles pour le champ marque sera jamais le changement (ou rarement), vous pouvez utiliser ENUM comme un compromis. Il combine une bonne vitesse avec une bonne lisibilité.
enumtype de données? Je pensais que c'était spécifique à MySQL.
Un peu relatif. Oui, les INT seront plus rapides, mais la question est de savoir si cela est perceptible dans votre situation. Les VARCHAR ne sont-ils que de petits mots ou des textes plus longs? et combien de lignes y a-t-il dans le tableau? S'il n'y a que quelques lignes, elles seront probablement entièrement mises en mémoire tampon (lorsque cela est souvent demandé), dans ce cas, vous ne remarquerez pas beaucoup de différence. Ensuite, bien sûr, il y a l'indexation, qui devient plus importante lorsque la table grandit. L'utilisation de SSD peut être plus rapide que celle de HD avec des requêtes optimisées. Les bons contrôleurs de disque accélèrent parfois les requêtes> 10x. Cela peut laisser de la place à l'utilisation de VARCHAR, ce qui facilite la lecture et l'écriture des requêtes (pas besoin d'écrire des jointures complexes) et accélère le développement. Cependant, les puristes seront en désaccord et normaliseront toujours tout.