PostgreSQL B-tree索引大小异常求助：不同类型字段索引尺寸相近且远超预期

嘿，这个问题我碰到过类似的情况，来帮你捋捋可能的原因，再聊聊索引大小估算的实用思路！

1. 为啥所有索引大小几乎一致？ #

这大概率是索引结构的固定开销和主键的影响在起作用：

• B-tree索引的每个页（page）都有固定的元数据开销——比如页头信息、节点指针、事务相关的ID等。当你的表有800万条这么大的体量时，这些固定开销在总大小里占比很高，直接掩盖了不同字段类型本身的存储差异。
• 如果你的表用的是聚簇索引（比如MySQL InnoDB的默认模式），所有二级索引的每个条目都得带着主键的值。要是你的主键是个比较大的类型（比如VARCHAR(255)或者bigint），那每个二级索引条目都会被这个主键“撑大”，最终不同字段的索引总大小自然就趋近一致了。
• 还有可能是数据库的**填充因子（fill factor）**设置统一，每个索引页的利用率差不多，加上固定的页大小（比如8KB），总大小也就因为页数接近而差别不大。

2. 布尔型索引为啥这么大？ #

这个核心原因几乎可以确定是聚簇索引主键的拖累：
比如InnoDB的二级索引，每个条目不仅要存布尔值（1字节），还得存主键值（假设是8字节的bigint），再加上事务ID、回滚指针这些元数据（大概10-15字节），单条索引条目就已经接近20-25字节了。800万条的话，8000000 * 25字节 = 200MB，和你说的217MB几乎吻合！
再加上B-tree页的页头开销（每个页大概100字节左右）和填充因子预留的空闲空间，最终总大小就会比纯字段计算的结果大一些。另外，布尔型虽然只有两个值，但B-tree不会对重复值做特殊压缩（除非你开了页压缩），所以每个条目还是完整存储，不会因为重复多而变小。

要估算索引大小，核心是把索引的空间占用拆成几部分来算：

• 字段本身的存储大小：比如布尔型1字节、int4字节、varchar(n)是实际长度+1字节等；
• 索引条目附加数据：比如二级索引要带的主键值、事务ID、回滚指针（InnoDB）、行指针（MyISAM）等；
• B-tree页的开销：每个页的页头、填充因子预留的空闲空间、页间指针等；
• 数据库特定额外开销：比如索引统计信息、分区信息（如果有）。

实用的参考内容 #

• 如果你用PostgreSQL，官方文档里的「Database Storage」章节详细讲了B-tree索引的结构和空间计算，包括索引条目、页结构的细节；
• 要是用MySQL/InnoDB，官方文档的「InnoDB Storage Engine」部分有聚簇索引、二级索引的空间占用说明，还有具体的计算示例；
• 通用估算公式：先算出单条索引条目的大小，乘以总记录数，再加上10%-20%的页开销（取决于填充因子），就能得到大致的索引大小范围。

另外，你可以用数据库自带的工具精准分析：比如PostgreSQL的pg_indexes_size()函数和stat_user_indexes视图，MySQL的information_schema.STATISTICS表和SHOW TABLE STATUS命令，这些能帮你看到每个索引的空间占用细节。

内容的提问来源于stack exchange，提问作者Mohsen