BIGINT mysql 性能与 INT 相比答案

【问题标题】：BIGINT mysql performance compared to INTBIGINT mysql 性能与 INT 相比
【发布时间】：2012-03-11 16:58:39
【问题描述】：

我正在尝试确定如果我将主键更改为 BIGINT(20)，我的表是否会降低性能。目前，我正在使用 INT(7) 并且已经有大约 300.000 个大 ID（7 位或 8 位数字）条目。我已经搜索了很多，但只发现它使用了更多的磁盘空间（这很明显）。

我现在所有的 ID 都是 7 位数字，但我的客户想要更改为 8 位数字。将来我将无法轻松更改软件，因此我考虑现在使用 BIGINT(20) 以防万一。即使我还不需要使用 BIGINT，它的性能会降低吗？

有这方面经验的人有没有关于速度和性能的建议？

【问题讨论】：

标签： mysql

【解决方案1】：

回答您的问题：是的，它的性能会降低。显然，类型越大，表越大，查询越慢（更多的 I/O、更大的索引、更长的访问时间、结果不太可能适合各种缓存，等等）。因此，根据经验：始终使用适合您需要的最小类型。

话虽如此，性能并不重要。为什么？因为当您到达溢出 INT 的地步时，BIGINT 是唯一的解决方案，您将不得不忍受它。同样在那时（考虑到您使用的是自动增量 PK，您将超过 4 billions 行），您将遇到更大的性能问题，并且与 INT 相比 BIGINT 的开销将是您最不关心的问题。

所以，请考虑以下几点：

如果您不需要负值，请使用 UNSIGNED，这会使限制加倍。
UNSIGNED INT 最大值为 4.294.967.295。如果您使用自动增量 PK，并且您只有 300.000 个条目，您真的不必担心。你现在甚至可以使用 MEDIUMINT，除非你计划实现非常快速的增长。（见http://dev.mysql.com/doc/refman/5.1/en/integer-types.html）
类型后括号中的数字不影响类型的最大值。 INT(7) 与 INT(8) 或 INT(32) 相同。如果您指定 ZEROFILL，则用于指示显示宽度（请参阅http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html）

【讨论】：

这说明了我要说的一切。除非您处理大量数据（其中 300,000 个条目不是），否则您几乎没有机会达到 INT 字段的限制。同样正如这里提到的， (7) 并没有真正做任何事情来限制字段存储的内容。您仍然有 43 亿的限制（假设您将其设为 UNSIGNED）
我知道 int(7) 的大小等等。但我没有在该表中使用自动增量，因为数字是从另一个数据库导入的，而且它们比 2 个字符长得多
它被导入的事实并不能阻止您使用 AUTO_INCREMENT - AI 值会在一系列插入后自动设置 PK 的最大值（如果不是，您可以使用 ALTER 更改它)。现在，如果您确实需要 BIGINT，因为您的数字长度可以超过 10 位（例如，序列号会发生这种情况），那么是的，它的效率会稍低一些。如果您真的很担心并且流量很大，您可以使用单独的（小）自动增量 PK 并将您的 BIGINT 存储为 UNIQUE INDEX（但坦率地说，我认为这不值得麻烦）
所以你认为它的性能并没有差多少？你在某个地方找到了测试吗？还是链接？
是的，我认为在这种情况下，开销是微不足道的，您不会注意到它。（我正在处理超过 4000 万行的表，使用 BIGINT 进行 PK 没有问题）

【解决方案2】：

不希望复活僵尸，但“现代”mysql 使用列类型 serial，它是一个 bigint(20) 无符号 NOT NULL AUTO_INCREMENT - 并且肯定表明 mysql 将（或将）被优化以使用bigint 作为主键。

此外，varbinary(16) primary 允许一个（我们这样做）使用 uuid_short() 作为主键（不是 uuid - 用作主键非常慢，因为它是一个字符串，而不是使用串行） ) - 它的特点是确保每条记录都有一个在整个数据库（实际上是网络）中唯一的键。

但请注意 - 一些强制转换会将 bigint 降级为 int 并导致不良结果。例如，如果您将字符串表示与大 int 进行比较 - 您可能会发现得到误报。所以必须使用二进制进行比较...例如

where id = binary id_str

我个人认为这是一个未修复的错误...

【讨论】：