Quelle est la différence de performances entre int et varchar pour les clés primaires

Je dois créer un schéma de clé primaire pour un système qui nécessitera une réplication entre homologues. Donc, je prévois de combiner un ID système unique et un numéro séquentiel d'une manière ou d'une autre pour trouver des ID uniques. Je veux m'assurer que je ne manquerai jamais d'ID, donc je pense utiliser un champ varchar, puisque je pourrais toujours ajouter un autre personnage si je commence à manquer. Mais j'ai lu que les entiers sont mieux optimisés pour cela. J'ai donc quelques questions ...Quelle est la différence de performances entre int et varchar pour les clés primaires

1) Les entiers sont-ils vraiment mieux optimisés? Et s'ils le sont, quelle différence y a-t-il entre les varchars et les entiers? Je vais utiliser Firebird pour le moment. Mais je peux changer plus tard. Ou peut-être soutenir plusieurs DB. Je cherche donc des généralisations, si c'est possible.

2) Si les entiers sont nettement mieux optimisés, pourquoi? Et est-il probable que les varchars rattraperont leur retard dans le futur, alors finalement cela n'aura pas d'importance?

Mes clés varchar n'auront aucune signification, sauf pour la partie ID système unique. Mais je pourrais vouloir cacher cela d'une façon ou d'une autre. Aussi, je prévois d'utiliser efficacement tous les bits de chaque personnage. Je ne prévois pas, par exemple, de coder l'entier 123 comme la chaîne de caractères "123". Donc, je ne pense pas que les varchars nécessiteront plus d'espace que les entiers.

Source

2011-01-09 user568576

Combien de rangées comptez-vous stocker? – zerkms

La plupart des systèmes seront petits et généreront probablement moins de 50 000 lignes par an. Mais il est possible que j'ajoute des fonctionnalités qui devront stocker beaucoup plus. En outre, certains systèmes consolideront les données provenant de nombreux systèmes différents.Et cela pourrait potentiellement provenir de milliers de systèmes. Donc, plutôt que d'essayer de trouver un maximum de lignes, je pense que je ferais mieux de planifier un très grand nombre. A moins que la performance ne soit trop forte. Ensuite, je vais reconsidérer. – user568576

Pour MySQL, selon Alexey here, la réponse est étonnamment "pas beaucoup". Il conclut:

Donc, si vous avez une application et que vous avez besoin d'un champ de table avec un petit ensemble de valeurs possibles, je vous suggère quand même d'utiliser ENUM, mais maintenant nous pouvons voir que la performance est atteinte peut ne pas être aussi grand que prévu. Bien que beaucoup dépend de vos données et requêtes.

Source

2011-01-09 06:42:31 Ken

Le test dans l'article auquel vous étiez lié n'est pas exactement analogue à sa situation, puisque le champ était utilisé pour finir une chaîne d'une façon ou d'une autre. Son test comparait mettre la chaîne dans un varchar pour mettre un uid dans un int et se joindre à une autre table pour obtenir la chaîne correspondante. En d'autres termes, il ne comparait pas l'utilisation d'un int comme une clé vs l'utilisation d'un varchar comme une clé, comme le demande l'OP. Grande différence. –

Merci, cela commence à me donner une idée de ce à quoi m'attendre. Un intervenant a laissé entendre que le rendement était étroitement lié à la taille de la clé, ce qui aurait du sens. Et je ne m'inquiète pas pour ça. Mais je me demande s'il y a beaucoup de différence entre un varchar 64 bits et un entier 64 bits? – user568576

Je n'ai pas encore lu attentivement l'article, donc il se peut qu'il ne s'applique pas directement. Mais balayant les commentaires après m'aidait à me donner un aperçu. Je voulais juste le mentionner, puisque je n'ai pas vu le commentaire de DJ avant de poster mon dernier. – user568576

Vous aurez probablement pas à court d'entiers. Par exemple, dans MySQL, la valeur maximale de BigInt est 18 446 744 073 709 551 615. Donc, si vous insérez 100 millions de lignes par seconde, il vous faudra 5849 ans avant de manquer de nombres.

Source

2011-01-09 07:34:15 Ronnis

Je considérais bigint. Mais j'ai lu un autre fil ici, et quelqu'un a mentionné que certains systèmes ne supportent pas bigint. Et il est possible que je doive exporter des données vers l'un de ces systèmes. Donc j'essaie d'éviter de devoir convertir bigint en caractères pour des systèmes comme ça. Mais je ne les ai pas encore exclues pour le moment. – user568576

@ user568576, avec "systèmes", voulez-vous dire différents dbms ou différents systèmes d'exploitation? – Ronnis

"Application" aurait été un meilleur terme. Mes utilisateurs peuvent avoir besoin d'exporter des données et de les utiliser dans une feuille de calcul, par exemple. Ensuite, ils pourraient vouloir que les données fusionnent d'une manière ou d'une autre. – user568576

varchar nécessite un stockage supplémentaire pour les informations de longueur
nécessite un traitement de classement
varchar peuvent ne pas correspondre à tous les systèmes en raison de la collation
int donne 4 milliards de lignes, bigint (8 octets) donne 18 billion de lignes
pré-bigint, j'ai vu décimal (19, 0) qui donne aussi 18 billions de lignes

U chanter varchar sera fin en larmes ...

Pour être clair: vous développez un système qui peut avoir plus de 4 milliards de lignes (vous ne savez pas ), a la réplication, vous don » t connaissez quel RDBMS vous utiliserez, et vous ne comprenez pas comment varchar diffère d'un entier?

Source

2011-01-09 10:56:25 gbn

Pour clarifier: * Tous les systèmes combinés pourraient avoir plus de 4 milliards de lignes. * Certaines données devront être répliquées. * Je commence avec firebird, mais je peux aussi avoir besoin de postgres. Différentes parties du système auront des exigences différentes. Je peux aussi changer d'avis. * C'est pourquoi je pose la question. – user568576

Je pensais à l'information sur la longueur supplémentaire, et je ne pense pas que cela aura de l'importance. Mais les trucs de collation pourraient être un problème. Je vais devoir faire d'autres recherches à ce sujet. – user568576

Je pense que je peux éviter les problèmes de classement en utilisant l'ordre binaire. Si je faisais cela, aurais-je des problèmes de correspondance entre les systèmes? Mes clés seront juste une série unique de bits sans signification, donc je pense que peu importe comment ils sont représentés à l'utilisateur final, s'il leur arrive de les voir. À moins qu'ils ne les exportent, les convertissent sans le savoir dans un autre jeu de caractères, puis les réimportent d'une manière ou d'une autre (je ne dis pas cela comme un problème). Est-ce que je manque quelque chose d'important? – user568576

Quelle est la différence de performances entre int et varchar pour les clés primaires

Répondre

Questions connexes