背景

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...)的方法》