与INT相比，BIGINT的mysql性能

Question

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

我的所有ID现在都有7位数，但我的客户想要更改为8位数。我将来无法轻易更改软件，因此我想考虑使用BIGINT（20）以防万一。如果我使用BIGINT，即使我不需要它也不会那么高效吗？

有经验的人是否有关于速度和性能的建议？

Answer 1

回答你的问题：是的，性能会降低。显然，类型越大，表越大，查询越慢（I / O越多，索引越大，访问时间越长，结果越不容易适应各种缓存，等等）。因此，作为经验法则：始终使用适合您需要的最小类型。

话虽如此，表现并不重要。为什么？因为当你到达溢出INT的点时，BIGINT是唯一的解决方案，你将不得不忍受它。此时（考虑到你正在使用自动增量PK，你将超过4 数十亿行），你会遇到更大的性能问题，以及与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）
，它用于指示显示宽度

Answer 2

不希望复活僵尸，但是“现代” mysql使用列类型serial，这是bigint（20）unsigned NOT NULL AUTO_INCREMENT-并建议将（或正在）优化mysql以使用bigint作为主键。

而且，bigint primary不使用串行，而是允许一个（我们这样做）将uuid_short（）用作主键（而不是uuid –用作主键非常慢，因为它是字符串）-具有确保每个记录具有在整个数据库（实际上是网络）中唯一的键的功能。