Isso realmente teria que ser medido, podemos fazer algumas "suposições" com base no que sabemos e no que assumimos, mas essas são apenas suposições.

Você não menciona se esta tabela é InnoDB, ou MyISAM com linhas dinâmicas ou MyISAM com linhas de comprimento fixo. Isso vai fazer alguma diferença.

Mas para valores como o que você postou, '961637593864109_412954765521130' (31 caracteres), supondo que você esteja usando um conjunto de caracteres de byte único (por exemplo, latin1), ou um conjunto de caracteres que codifica esses caracteres específicos em um único byte (por exemplo, utf8)...

Para o formato dinâmico InnoDB e MyISAM, são 31+1-8=24 bytes extras para essa linha. (BIGINT cabe em 8 bytes, um valor VARCHAR(31) de 31 caracteres usará 32 bytes.)

Para a tabela MyISAM com linhas de comprimento fixo, isso seria uma diferença de 23 bytes por linha. (O espaço é reservado para todos os 31 caracteres e o comprimento não precisa ser armazenado.)

Esse valor de chave primária também será repetido em cada índice, portanto, também há um espaço maior com cada índice.

Supondo que as linhas da sua tabela tenham 120 bytes usando BIGINT e as linhas tenham 144 bytes com VARCHAR, isso é 20% aumentar. Quanto maiores suas linhas, menor o aumento percentual e vice-versa.

Para 1.000.000 de linhas (eu quero dizer "one meelyun rows" da mesma forma que o Dr. Evil coloca o dedo mindinho no canto da boca e diz "um milhão de dólares"), esses 24 bytes extras por linha totalizam cerca de 24 MB.

Mas não é tão fácil assim. Em termos de espaço InnoDB, é uma questão de como as linhas podem "se encaixar" em um bloco. Quanto maior o tamanho médio da linha, maior será a quantidade de espaço livre em um bloco.

Se você não fizer nada com as linhas, exceto armazená-las em disco, será apenas um aumento no espaço em disco e tempo e espaço extras para backups.

Se o mesmo número de linhas de "144 bytes" caber em um bloco como linhas de "120 bytes", você não verá nenhuma diferença no espaço. Mas se menos linhas couberem em um bloco, isso significa mais blocos, mais espaço no buffer pool do InnoDB, mais i/o, etc.

Para consultas de uma única linha, seja por valor de chave primária ou por alguma outra pesquisa de índice exclusivo, a diferença será insignificante.

Se você estiver lidando com conjuntos de resultados maiores, isso é memória extra para preparar o conjunto de resultados e bytes extras para transferir para o cliente etc.

Se a chave VARCHAR for projetada de tal forma que "grupos" de linhas que são acessadas juntas tenham a mesma parte inicial do valor da chave, então com o InnoDB, pode haver alguma melhoria de desempenho. Isso ocorre porque a chave primária é a chave do cluster... chance muito maior de as linhas necessárias para satisfazer uma consulta estarem no mesmo bloco, em vez de serem espalhadas por vários blocos.

O inverso é que se houver inserções e exclusões realizadas, haverá mais espaço livre em alguns blocos. (Com as exclusões, o espaço para linhas excluídas permanece no bloco; para reutilizá-lo, você precisa inserir uma linha que tenha o mesmo valor de chave (ou pelo menos um valor de chave próximo o suficiente para cair no mesmo bloco .) E com inserções aleatórias, teremos divisões de blocos.