这确实必须进行衡量，我们可以根据我们所知道的和我们假设的情况做出一些“猜测”，但这些只是猜测。
您没有提及该表是 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 行（我很想说“one meelyun rows”，就像邪恶博士将小指放在嘴角说“100 万美元”一样）每行额外的 24 个字节总计约为 24MB。
但这并不是那么容易。就 InnoDB 空间而言，问题在于如何将行“适合”到块中。平均行大小越大，块中的可用空间量就越大。
如果除了将行存储在磁盘上之外不对这些行执行任何操作，那么实际上只是增加了磁盘空间以及用于备份的额外时间和空间。
如果块中适合的“144 字节”行数与“120 字节”行数相同，那么您不会看到任何空间差异。但是，如果一个块中容纳的行数较少，那么块数就会增加，InnoDB 缓冲池中的空间就会增加，I/O 也会增加，等等。
对于单行查询，无论是通过主键值还是通过其他唯一索引查找，差异都可以忽略不计。
如果您正在处理较大的结果集，则需要额外的内存来准备结果集，以及传输到客户端的额外字节等。
如果 VARCHAR 键的设计方式使得一起访问的行“组”具有相同的键值前导部分，那么使用 InnoDB，实际上可能会有一些性能改进。这是因为主键是簇键……满足查询所需的行更有可能位于同一个块中，而不是分散在一堆块中。
相反，如果执行插入和删除，某些块中将会有更多的可用空间。 （通过删除，已删除行的空间保留在块中；要重用该空间，您需要插入具有相同键值的行（或者至少有一个足够接近的键值，使其位于同一块中） .）通过随机插入，我们将得到块分割。
