Cela devrait vraiment être mesuré, nous pouvons faire des "suppositions" basées sur ce que nous savons et ce que nous supposons, mais ce ne sont que des suppositions.
Vous ne mentionnez pas si cette table est InnoDB, ou MyISAM avec des lignes dynamiques, ou MyISAM avec des lignes de longueur fixe. Cela va faire une différence.
Mais pour des valeurs comme celle que vous avez postée, '961637593864109_412954765521130' (31 caractères), en supposant que vous utilisez un jeu de caractères à un seul octet (par exemple, latin1) ou un jeu de caractères qui code ces caractères particuliers en un seul octet (par exemple, utf8)...
Pour le format dynamique InnoDB et MyISAM, c'est 31+1-8=24 octets supplémentaires pour cette ligne. (BIGINT tient dans 8 octets, une valeur VARCHAR(31) de 31 caractères utilisera 32 octets.)
Pour la table MyISAM avec des lignes de longueur fixe, ce serait une différence de 23 octets par ligne. (L'espace est réservé pour les 31 caractères et la longueur n'a pas besoin d'être stockée.)
Cette valeur de clé primaire sera également répétée dans chaque index, de sorte qu'il y a également plus d'espace avec chaque index.
En supposant que les lignes de votre tableau font 120 octets avec BIGINT et que les lignes font 144 octets avec VARCHAR, cela représente 20 % augmenter. Plus vos lignes sont grandes, plus le pourcentage d'augmentation est faible, et vice versa.
Pour 1 000 000 lignes (je veux tellement dire "une ligne meelyun" de la même manière que le Dr Evil met son petit doigt au coin de cette bouche et dit "un million de dollars"), ces 24 octets supplémentaires par ligne totalisent environ 24 Mo.
Mais ce n'est pas si facile. En termes d'espace InnoDB, il s'agit de savoir comment les lignes peuvent "s'intégrer" dans un bloc. Plus la taille moyenne des lignes est grande, plus la quantité d'espace libre sera importante dans un bloc.
Si vous ne faites rien d'autre avec les lignes que de les stocker sur le disque, il s'agit en réalité d'une augmentation de l'espace disque et du temps et de l'espace supplémentaires pour les sauvegardes.
Si le même nombre de lignes "144 octets" tient dans un bloc que de lignes "120 octets", vous ne verrez aucune différence d'espace. Mais si moins de lignes tiennent dans un bloc, c'est plus de blocs, plus d'espace dans le pool de mémoire tampon InnoDB, plus d'E/S, etc.
Pour les requêtes d'une seule ligne, soit par valeur de clé primaire, soit par une autre recherche d'index unique, la différence sera négligeable.
Si vous avez affaire à des ensembles de résultats plus volumineux, il s'agit de mémoire supplémentaire pour préparer l'ensemble de résultats et d'octets supplémentaires à transférer vers le client, etc.
Si la clé VARCHAR est conçue de manière à ce que les "groupes" de lignes accessibles ensemble aient la même partie principale de la valeur de la clé, alors avec InnoDB, il peut y avoir une amélioration des performances. C'est parce que la clé primaire est la clé du cluster... beaucoup plus de chances que les lignes nécessaires pour satisfaire une requête se trouvent dans le même bloc, plutôt que d'être réparties sur un tas de blocs.
L'inverse est que si des insertions et des suppressions sont effectuées, il y aura plus d'espace libre dans certains blocs. (Avec les suppressions, l'espace pour les lignes supprimées reste dans le bloc ; pour le réutiliser, vous devez insérer une ligne ayant la même valeur de clé (ou au moins une valeur de clé suffisamment proche pour qu'elle atterrisse dans le même bloc .) Et avec des insertions aléatoires, nous allons obtenir des fractionnements de blocs.
