oracle中的低基数高更新列应该创建什么索引？答案

【问题标题】：What index should be created for low cardinality high updating columns in oracle?oracle中的低基数高更新列应该创建什么索引？
【发布时间】：2016-02-22 15:09:54
【问题描述】：

例如，在 Oracle 11g 中，我有一个表 Task，其中有一列 ProcessState。该列的值可以是Queued、Running 和Complete（将来可以有更多的状态）。该表将包含 50M+ 数据，其中 99.9% 的行具有 Complete 作为该列值。只有几千行的值为Queued/Running。

我读到虽然bitmap 索引适用于低基数列，但主要用于静态表。

那么，什么索引可以改善Queued/Running任务的查询呢？ bitmap 还是普通的非唯一 b-tree 索引？

此外，什么索引可以改进对二进制列的查询（NUMBER(1,0) 仅具有 yes/no 值）？

免责声明：我是一名偶然的 dba。

【问题讨论】：

在您的情况下，“位图索引”更可取。您说“...99.9% 的行具有 Complete...”，如果您仅从一个会话更新 Task.ProcessState，您将不会对性能产生影响，否则会话将不得不序列化它对索引的访问。
您要改进的查询是什么？
@a_horse_with_no_name 像这样：select task_id from task where processstate=0（预计只有

标签： database oracle oracle11g database-administration database-indexes

【解决方案1】：

我猜您有兴趣选择具有（排队/运行）状态的行来更新它们。所以最好将已完成的行与其他行分开，因为索引已完成的行没有太多意义。您可以在此处使用 partitioning 或 基于函数的索引 使用函数返回 NULL 以获取已完成的行，并为其他行使用实际值，在这种情况下，索引中只会出现未完成的行树。

【讨论】：

【解决方案2】：

常规 (b*tree) 索引很好。只需确保列上有直方图即可。（参见DBMS_STATS.GATHER_TABLE_STATS 中的METHOD_OPT 参数）。

通过该列的直方图，Oracle 将获得所需的数据，以确保在查找排队/正在运行的作业时使用索引，但在查找已完成的作业时使用全表扫描。

不按照 cmets 中的建议使用位图索引。如果有大量更新，您将遇到并发问题，更糟糕的是，还会出现死锁问题。

此外，什么索引可以改进对二进制列的查询（NUMBER(1,0)，只有是/否值）

对不起——我错过了你问题的这一部分。如果列中的数据是倾斜的（即几乎全为 1 或几乎全为 0），则如上的常规 (b*tree) 索引。如果数据是均匀分布的，那么没有索引会有所帮助。通过索引读取表中 50% 的行将比全表扫描慢。

【讨论】：

常规（b-tree）索引很好 — 可以，但是在索引中包含不断增长的完整状态行集是低效的。在一般情况中增长完整状态记录集的唯一合适方法是FTS。因此，我们在索引维护方面获得了开销而没有任何收益。所以恕我直言，最好只索引非完整状态行。
我尽量保持我的回答简单；使用给出的信息。在我看来，OP 被推入了 DBA 角色，并试图提高现有应用程序的性能。基于函数的索引可用于省略“已完成”记录，但随后您必须更改应用程序查询以使用相同的函数，否则您将得不到任何好处。我不认为他有时间、权力等来做出这样的改变。有了他描述的表和他给出的查询目标，ProcessState 上的 b*tree 索引将是一个快速有效的解决方案，即使它确实会浪费一些空间