PostgreSQL BRIN INDEX 看完后我保证你会闭不上嘴

众所周知，PostgreSQL 各种插件的数据量和他无底洞的功能丰富性，被使用者所叹服。而PostgreSQL 有一种索引，BRIN 肯能使用的人不是很多，或许你也可能第一次听说这个索引的名字。相比 GIST ，GIN 这样的索引类型，BRIN 的名声可能稍有差距。那今天我们就来看看 BRIN 到底能做什么，为什么而生。

我们先创建一个表

插入一些数据 （当然这些数据是针对Brin 索引的数据）

我们通过下面的查询来看一下在没有索引的情况下查询时间类型的数据会怎样。

从下图我们可以对比出，添加索引后和全表扫描之间的cost 差距

从上图可以看出，添加索引后，查询的速度提高了，但我们的关键点不在这里，我们是要比较，BTREE 索引 和 BRIN 索引之间的不同点。

我们在同样的表的同样的字段创建，不一样类型的索引。通过图形中我们可以看出创建两种索引的时间是不一样的，brin 索引的速度比 BTREE 索引要快大约不到 12倍。

我们在对比一下两种索引的尺寸，看完下图，我估计你的嘴应该不会闭上，或许还会发出点声音。的确 BRIN 索引的尺寸是超小的，当然也是有原因的。

我们继续，那这样小的索引，对比BTREE 索引，到底查询的效率是不是可以满足要求呢？

我们可以看出，在默认的情况下，系统会默认使用 BTREE 索引，在两种索引都存在的情况下。

对比 BRIN 索引，虽然BRIN 索引比BTREE 索引慢了 些许毫秒，但对比索引所占用的空间比，BTREE 占用 129MB 而 BRIN 占用 56KB 你就能体会，你第二次长大的嘴，BRIN 索引真的很厉害。

说完上面那些，我们的谈谈，到底BRIN 索引是怎么做到的，大幅度降低索引的存储空间，并且还保证超高的索引查询中的查询率。

原因，BRIN 索引是一种有损索引，这个索引的简称 Block Range Index， 而BRIN 索引产生的主要原因也是为了一些 “超级大表的索引”，试想一下，你有一张6亿条记录的表，很可能你的索引就是几个G ，而这样的索引在查询中，其实随着数据量的增大，性能是线性下降的。

而BRIN 所以存储的数据并不是普通索引那样的 BTREE 的数据，而是存储元祖数据，以及相关数据的页面信息，通过这些信息，大大减少了存储数据的空间，而在判断数据是否符合条件的情况下，则比BTREE 索引要付出更多的过滤和对比的过程，但相对他超高的性价比，对于大表， 有序型的数据的索引的建立，BRIN 索引是值得被考虑和使用的。

当然如果有人问，这里面BRIN 索引是否牵扯类似压缩比率这样的事情

pages_per_range ，如果你将每页的范围调整过大，则损失就会越大，所以我们也可以在 “压缩” 和 准确度，之间做一个平衡。

最后我们来回顾一下，使用BRIN 索引的主要场景和目的

1 大表的索引性能问题

2 表中索引的数据在表中的字段最好是顺序型的，例如日期，或者某些可以顺序化的场景（其实时序数据库就符合这样的类型）

3 对索引占用空间敏感的场景。

OK， 如果到这里你还张着嘴，PLEASE ,我都看见口水了。