MySQL INT类型是5个字节?

时间:2015-07-28 01:38:40

标签: mysql performance

我有没有办法让一个使用5个字节的INT列?原因是INT(4字节)分配40亿个整数对我的应用程序来说还不够,但是BIGINT(8字节)是一种过度杀伤性能会影响性能,因为MySQL需要查看更大的磁盘空间任何事情,特别是当我们有数十亿行时,主键的额外存储空间将是多GB。

MySQL中是否有类似5字节的INT列?有没有什么我可以轻松定制调整MySQL来获得它?

2 个答案:

答案 0 :(得分:4)

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

但是,在深入阅读问题来源时,似乎对与BIGINT相关的开销有一些误解。

是的,您正在查看该列的数据存储量的两倍,但MySQL中的每一行都有:

  1. 您的聚集索引(PK)的13字节标头
  2. 每个索引记录的6字节标题
  3. 每个非索引记录的1个字节指针
  4. (见这里:https://dev.mysql.com/doc/refman/5.1/en/innodb-table-and-index.html#innodb-physical-record

    因此,假设它是唯一的列,您只需将BIGINT切割为5个字节((8-5)/(8 + 13)),就可以将行大小增加约14%在你的桌子里。

    如果使用COMPACT行格式并消除PK,则每行可节省8个字节(将索引减少到5个字节)。

    BIGINT与INT对您的索引的性能影响可以忽略不计(尽管由于丢失了群集而消除您的PK可能会导致一些明显的性能损失)。

    存储影响也可以忽略不计 - 你在大约80亿的普通性上看到~20 GB的影响。现代存储解决方案应该吃掉它。

答案 1 :(得分:1)

你没有说是AUTO_INCREMENT。如果不是:

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

将以5个字节为您提供最多99,999,999,999。

唉,AUTO_INCREMENT不能是DECIMAL

BIGINT中的额外4个字节(超过INT)加起来为一百万行近似N * 4MB,其中N是对列的引用数。假设它是PRIMARY KEY,这里是如何计算引用:

  • Data + PRIMARY KEY,一起计为1
  • 每个辅助密钥计为1个
  • 存储该ID的其他表计为1