背景
1、产品的问题点
- PG 不会自动选择索引类型
2、问题点背后涉及的技术原理
- PG 支持很多种类的索引, hash, btree, gin, gist, sp-gist, brin, bloom, 还有外置的rum, pase, zombodb等.
- 每种索引的存储结构都不一样, 可以加速的场景也不一样
- 《PostgreSQL 9种索引的原理和应用场景》
- btree，适合任意单值类型，可用于
=, >, <, >=, <=以及排序。 - hash，当字段超过单个索引页的1/4时，不适合b-tree索引。如果业务只有
=的查询需求，使用hash index效率更高. - gin，倒排存储，（column value: row IDs tree|list）。适合多值列，也适合单值列。例如数组、全文检索、JSON、HSTORE等类型。
- gist，适合数据有交错的场景，例如 全文检索、range类型、空间类型(点、线、面、多维对象... ...)。
- sp-gist，空间分区索引类型，适合不平衡数据集(例如xxxyyyzzz??????组成的VALUE，xxx, yyy, zzz，每个值包含一些数据集，每个数据集的数据量不平衡可能导致TREE不平衡)。
- brin，块级索引，记录每个或每连续N个数据块的数据边界。
- bloom，支持被索引字段的任意组合的等值搜索。
- rum，支持全文检索类型，支持单值列+全文检索列，支持近似文本搜索。
- zombodb，PG与ES搜索引擎结合的一种索引，在PG数据库中透明使用ES。
- bitmap，支持1000~10000个唯一值的列。适合多个值的 与或 条件搜索。
3、这个问题将影响哪些行业以及业务场景
- 通用, 但是这是富人的烦恼, 别的库没这么多索引种类
4、会导致什么问题?
- 一般用户不懂那么多, 通常只使用默认的btree, 使得无法达到最优化的数据库使用, 浪费资源
5、业务上应该如何避免这个坑
- 自己掌握这些索引的原理, 根据实际的业务需要进行选择.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 学习门槛
7、数据库未来产品迭代如何修复这个坑
- 希望能在语法层支持自动分析, 自动推荐索引种类. 根据数据类型、数据分布、where 条件的表达式和操作符进行自动选择.
- 《自动选择正确索引访问接口(btree,hash,gin,gist,sp-gist,brin,bitmap...)的方法》
