与INT相比,BIGINT的mysql性能

Question

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

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

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

Answer 1

回答你的问题:是的,性能会降低.显然,类型越大,表越大,查询越慢(I/O越多,索引越大,访问时间越长,结果越不容易适应各种缓存,等等).因此,根据经验:始终使用最适合您需要的类型.

话虽如此,性能并不重要.为什么？因为当你到达溢出INT的点时,BIGINT是唯一的解决方案,你将不得不忍受它.此外(考虑到你正在使用自动增量PK,你将超过40 亿行),你将遇到更大的性能问题,与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 作为首要的关键。

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

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

where id = binary id_str

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