sql - 低选择性色谱柱的索引和替代品

Question

可用于选择低选择性列上的记录的策略范围有哪些？

一个例子可能是一个订单表，多年来，您建立了大量已完成的订单，但通常需要选择事件订单。订单可能会经历一个生命周期，例如下达、分配库存、从仓库中提取、发送给客户、开具发票和付款。订单可能还会被取消、保留等。大多数记录最终将处于最终状态(例如已付款)，但您可能经常需要选择，例如已分配的订单。在这种情况下，顺序读取会很慢。

关于索引的类似问题
MySQL: low cardinality/selectivity columns = how to index?
Do indexes suck in SQL?
What are indexes and how can I use them to optimize queries in my database?
Defining indexes: Which Columns, and Performance Impact?
和许多其他人越来越少相关。

我读过的方法(在 stackoverflow 和其他地方)包括

使用位图索引

使用部分索引 ( create index x on t(c2) where c1='a' )

使用聚集索引？

不要索引低选择性列，使用顺序读取

对数据进行分区(例如，将数据分成多个具有相同架构的表)

使用补充表(例如 active_customers(customer_id)

我当前的 DBMS 不支持上面列出的前三个选项，其余的似乎有问题——还有其他常用的方法吗？

更新:我见过
- 索引您的低选择性列，但只选择高选择性值。

Answer 1

在您列出的所有方法中，只有一种(使用顺序读取)是与低选择性有关的方法(好吧，集群也可以)。

如果您对列的选择性较低，这意味着扫描将比查找执行得更好。

索引可以用来做

索引查找 - 检查索引指针，检索记录，重复

索引扫描 - 扫描索引并直接从索引中获取值

否则它不是很有用。

如果选择性低，则意味着将读取索引的大部分，如果使用查找，则将以某种随机顺序读取大部分数据。如果您覆盖了基础表的很大一部分，这将是低效的，因此更好的方法是进行顺序读取(这也很慢)。

因此，如果选择性低，则您无能为力(聚类可以提供帮助)。

然而 ，我不相信你明白在你的例子中你 不要选择性低。正如您所说，大多数参赛作品将获得报酬，而分配的参赛作品很少。这些(分配的)条目将具有高选择性。特别是如果有附加条件 如果 有一个包含这些附加条件的复合索引。

所以，你可能会撞到一个没有问题的人。

现在，确实可以通过对数据进行分区或使用补充表(如果需要)来进一步提高性能。