我已经读过像23423423423423423637这样对于primare唯一键的bigint比varchar更好像961637593864109_412954765521130但如何大的差异当有让我说100万行时我永远不会排序但只能选择/更新一行。使用varchar对我来说会更舒服，当性能差异低于30％或任何事情时，我将保持这种状态。我无法找到任何基准。
答案 0 :(得分：1)
这真的需要衡量，我们可以做一些＆＃34;猜测＆＃34;基于我们所知道的和我们所假设的，但这些只是猜测。
您没有提及此表是InnoDB，还是具有动态行的MyISAM，还是具有固定长度行的MyISAM。这会产生一些影响。
但是对于您发布的值'961637593864109_412954765521130'（31个字符），假设您使用单字节字符集（例如latin1），或者将这些特定字符编码为单个字节的字符集（例如utf8）......
对于InnoDB和MyISAM动态格式，该行的31 + 1-8 = 24个额外字节。 （BIGINT适合8个字节，31个字符的VARCHAR（31）值将使用32个字节。）
对于具有固定长度行的MyISAM表，这将是每行23个字节的差异。 （所有31个字符都保留空格，并且不必存储长度。）
每个索引中也会重复该主键值，因此每个索引的空间也会增加。
假设您的表行使用BIGINT为120字节，并且行使用VARCHAR为144字节，则 20％增加。行数越大，增加的百分比越小，反之亦然。
对于1,000,000行（我想说＆＃34;一行meelyun行＆＃34;就像Evil博士将他的小拇指放在这个嘴的角落并说＆＃34;一百万美元＆＃ 34;）每行额外24个字节总计大约24MB。
但它并不那么容易。就InnoDB空间而言，它是一个关于行如何适应＆＃34;的问题。陷入困境。平均行大小越大，块中的可用空间量就越大。
如果你不对行进行任何操作，除了将它们存储在磁盘上，那么它实际上只是增加了磁盘空间，增加了备份的时间和空间。
如果相同数量的＆＃34; 144字节＆＃34;行在一个块中适合作为＆＃34; 120字节＆＃34;行，那么你就不会看到空间上的任何差异。但是如果一个块中的行数更少，那么更多的块，InnoDB缓冲池中的空间更多，i / o更多等等。
对于单行的查询，无论是通过主键值还是通过其他一些唯一索引查找，差异都可以忽略不计。
如果您正在处理更大的结果集，那么就是用于准备结果集的额外内存，以及要传输到客户端的额外字节等。
如果VARCHAR键的设计方式是＆＃34; group＆＃34;一起访问的行具有与键值相同的前导部分，然后使用InnoDB，实际上可能会有一些性能改进。这是因为主键是群集密钥...满足查询所需的行更有可能在同一个块中，而不是分散在一堆块上。
相反的是，如果执行了插入和删除，则某些块中将有更多可用空间。 （使用删除时，已删除行的空间仍保留在块中;要重新使用该行，您需要插入具有相同键值的行（或至少一个足够接近其键入的键值）相同的块。）随着随机插入，我们将进行块分割。