背景

1、产品的问题点

• PG 不支持分区索引

2、问题点背后涉及的技术原理

• PG的索引支持到表级别, 如果是分区表那么每个分区创建对应索引, 索引不能单独进行分区. 例如一个100亿条记录的单表, 如果要创建索引只能创建普通索引, 索引本身不能分区.

3、这个问题将影响哪些行业以及业务场景

• 当单表较大时

4、会导致什么问题?

• 单表较大时, 索引也会非常庞大, 可能带来一些问题:

• • 创建索引的耗时变长,
  • 索引深度变大导致性能下降,
  • 索引的垃圾回收时间变长.
  • 如果系统中有多个块设备、多个表空间, 由于1个索引只能存放在1个表空间内, 那么无法很好的利用多个块设备的性能.

5、业务上应该如何避免这个坑

• 避免单表(或单一分区)的数据量过大, 例如不超过10亿条记录(经验). 超过后建议分区.

• • 如果更新频率巨大, 例如建议单个分区不超过1亿条(经验)

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 管理成本增加

7、数据库未来产品迭代如何修复这个坑

• 内核层面支持分区索引, 如果是分区表则可以支持指定其他索引分区键.

• • 根据某些表达式、字段HASH、范围分区

• 每个索引分区可以指定不同的表空间.