在使用MyISAM时，在使用INT和BIGINT时是否节省了索引大小？

Question

在使用INT类型与BIGINT类型时，数据列的每一行空间显然节省了4个字节。

但我一直在试图弄清楚，对于整数上的myisam索引是否也有任何节省空间，因为它们通常是解压缩的。

MySQL没有说明索引的结构类型-它只调用单元“节点”，然后没有提到它们的实际大小。

因此，给定相同的一组数字，比如一百万行整数，使用INT而不是BIGINT会减少节点大小吗？或者因为尽管存在整数范围，仍然可以有无限的行数，节点大小是否总是必须相当大？

我想我可以编一个演示来测试这个问题，但是也许已经有人在技术层面上正确地理解了这个问题，并且可以解释它。

Answer 1

我认为这很容易调查我自己，尽管我仍然不理解为什么(请允许详细说明)的基本细节。

答案是:是的，int无疑比BIGINT创建更小的索引。

我创建了两个表，第一个表有四个无符号INT列，第二个表有四个未签名的BIGINT。

我为每个表的所有四列建立了一个复合索引。

然后，我在每个表中添加了一百万行随机无符号小点( 0-65535 )。

(每个表都有相同的数据，包括数字和行顺序)

然后我对这两个表进行了优化和刷新，只是为了确定。

INT

Data    17,000  KiB
Index   31,610  KiB
Total   48,610  KiB

BIGINT

Data    33,000  KiB
Index   56,921  KiB
Total   89,921  KiB

17,408,000 int.MYD
32,368,640 int.MYI

33,792,000 bigint.MYD
58,287,104 bigint.MYI

添加：

我担心重复的随机数据(我发现了一些案例)。

因此，我在每个表中添加了一个带有自动增量的主列，并将其清空。然后，我在每一列中填写数字从1到1,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

INT

Data    20,508  KiB
Index   32,301  KiB
Total   52,809  KiB

BIGINT

Data    40,039  KiB
Index   54,178  KiB
Total   94,217  KiB

因此，即使在索引存储方面，也不能节省50%的费用，但绝对是加起来的。