MySQL INT类型为5字节？

有没有办法让INT列使用5个字节？原因是，分配40亿个整数的INT（4字节）对于我的应用程序来说还不够，但是BIGINT（8字节）是一种过度使用，这会影响性能，因为MySQL必须在更大的磁盘空间中查找任何内容，特别是当我们有数十亿行时，主键的额外存储空间将是许多GB

---

MySQL中是否有类似于5字节整数列的内容？有什么东西我可以轻松地自定义调整MySQL来获得吗？

简单的答案是没有-没有任何5字节的整数字段

然而，当深入阅读问题的来源时，似乎对与BIGINT相关的开销有一些误解

是的，该列的数据存储量增加了一倍，但MySQL中的每一行都有：

用于聚集索引（PK）的13字节头

每个索引记录的6字节头

每个非索引记录一个1字节的指针

（见此处：）

因此，如果BIGINT是表中唯一的一列，那么通过将BIGINT减少到5字节（（8-5）/（8+13））只会将行大小增加14%

如果使用压缩行格式并消除PK，则每行可以节省8个字节（将索引减少到5个字节）

使用BIGINT vs INT时，索引对性能的影响可以忽略不计（尽管消除PK可能会由于集群丢失而导致一些明显的性能损失）

---

对存储的影响也可以忽略不计—您看到的是大约20 GB的影响，通常为80亿左右。现代存储解决方案应该会吃掉它。

您没有说它是否是

自动增量。如果没有：

mysql> CREATE TABLE DecPk ( d DECIMAL(11,0) NOT NULL PRIMARY KEY ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.14 sec)

将在5个字节内为您提供最多9999999999

唉，
自动增量
不能是
十进制

BIGINT
（超过
INT
）中额外的4个字节加起来约为N*4MB，用于一百万行，其中N是对列的引用数。假设它是一个
主键
，下面介绍如何计算引用数：


数据+主键一起计为1
每个辅助键都计为1
存储该id的其他表计为1
假设您在gjven列上有一个索引，那么
INT
和
BIGINT
之间的性能差异应该没有那么大。存储空间增加50%对你来说真的是个大问题吗？@Tim，是这样吗？MySQL不需要通过更大的磁盘存储吗？是的，
BIGINT
会有更多的存储空间，但是如果列上有索引，那么查找时间应该仍然很快。看到@StevenMoseley给出的答案了吗？真的吗？“现代存储解决方案应该把它吃光。”有没有任何来源支持它？是的，但SSD仍然非常小而且昂贵。我们的应用程序在SSD上。我错误地将你的话视为“现代存储引擎”，我认为存储引擎足够聪明，可以以智能的方式使用浪费的存储，简单的经验法则是：InnoDB磁盘空间是计算数据类型中字节的2-3倍。@kavoir.com-你真幸运！