Existe-t-il une différence de performance réelle entre les clés primaires INT et VARCHAR?

Question

Est-il mesurable de la performance différence entre l'utilisation d'INT vs VARCHAR comme clé primaire dans MySQL? Je voudrais utiliser VARCHAR comme la clé primaire de listes de référence (pensez aux Etats-unis, les Codes de Pays) et un collègue de travail, ne cédera pas sur l'INT AUTO_INCREMENT comme clé primaire pour toutes les tables.

Mon argument, comme détaillé ici, c'est que la différence de performances entre INT et VARCHAR est négligeable, puisque tous les INT référence de clé étrangère nécessitera une JOINTURE à donner un sens à la référence, un VARCHAR clé de présenter directement les informations.

Donc, quelqu'un a une expérience avec ce particulier de cas d'utilisation et les problèmes de performances qui en découlent?

Answer 1

Vous faites un bon point que vous pouvez éviter certains nombre de rejoint requêtes en utilisant ce qu'on appelle une clé naturelle au lieu d'une clé de substitution. Vous seul pouvez déterminer si l'avantage est important dans votre application.

Qui est, vous pouvez mesurer les requêtes dans votre application qui sont les plus importants pour être rapide, parce qu'ils travaillent avec de grands volumes de données ou ils sont souvent exécutée. Si ces requêtes bénéficier de l'élimination d'une jointure, et ne pas souffrir à l'aide d'un varchar de clé primaire, puis le faire.

Ne pas utiliser la stratégie pour toutes les tables de votre base de données. Il est probable que dans certains cas, une clé naturelle est mieux, mais dans d'autres cas, une clé de substitution, c'est mieux.

D'autres gens de faire un bon point qu'il est rare, dans la pratique, pour une clé naturelle pour ne jamais changer ou ont des doublons, donc les clés de substitution sont généralement en vaut la peine.

Answer 2

Ce n'est pas une question de performance. Il s'agit de ce qui fait une bonne clé primaire. Unique et immuable dans le temps. Vous pouvez penser qu'une entité telle qu'un code de pays ne change jamais au fil du temps et serait un bon candidat pour une clé primaire. Mais l'expérience amère est rarement le cas.

INT AUTO_INCREMENT remplit la condition "unique et invariable dans le temps". D'où la préférence.

Answer 3

Dépend de la longueur.. Si le varchar sera de 20 caractères, et l'int est de 4, alors si vous utilisez un int, votre index aura CINQ fois le nombre de nœuds par la page d'index de l'espace sur le disque... ce Qui signifie que la traversée de l'indice aurez besoin d'un cinquième comme beaucoup de physique et/ou logique lit..

Donc, si la performance est un problème, compte tenu de la possibilité, toujours utiliser une partie intégrante de la non-significatif de la clé (appelé à une mère porteuse) pour vos tables, et pour les Clés Étrangères qui référence les lignes de ces tableaux...

Dans le même temps, de garantir la cohérence des données, chaque table où il des questions qui devraient aussi avoir un sens non-numérique autre clé, (ou un Index unique) pour s'assurer que les doublons de lignes ne peut pas être inséré (double basé sur des attributs de table) .

Pour l'utilisation spécifique dont vous parlez (comme l'état des recherches ), il n'a pas vraiment d'importance parce que la taille de la table est petite.. En général il n'y a pas d'impact sur la performance à partir d'indices sur des tables avec moins de quelques milliers de lignes...

Answer 4

Absolument pas.

J'ai effectué plusieurs ... plusieurs ... contrôles de performances entre INT, VARCHAR et CHAR.

10 millions de tables d’enregistrement avec une PRIMARY KEY (unique et en cluster) ont exactement la même vitesse et la même performance (et le coût des sous-arbres) quel que soit le modèle que j’ai utilisé.

Cela étant dit ... utilisez ce qui convient le mieux à votre application. Ne vous inquiétez pas pour la performance.

Answer 5

Pour les codes courts, il n'y a probablement pas de différence. Cela est particulièrement vrai pour la table contenant ces codes sont probablement très faible (quelques milliers de lignes au plus) et ne pas changer souvent (quand est la dernière fois que nous avons ajouté un nouvel État AMÉRICAIN).

Pour les grandes tables avec une large variation entre la clé, cela peut être dangereux. Pensez à utiliser l'e-mail/nom d'utilisateur de l'Utilisateur table, par exemple. Ce qui se passe quand vous avez quelques millions d'utilisateurs, et certains de ces utilisateurs ont des noms longs ou des adresses e-mail. Maintenant, chaque fois que vous devez joindre à cette table à l'aide de cette clé, il devient beaucoup plus cher.