为什么我们对唯一列使用密集索引？答案

【问题标题】：Why do we use dense indexes for unique columns?为什么我们对唯一列使用密集索引？
【发布时间】：2021-04-14 22:12:58
【问题描述】：

我正在阅读有关 Oracle 数据库索引的内容，但有些地方我无法理解，为什么我们需要密集索引，尤其是在唯一列的密集索引的情况下？事实上，我们的数据库表上的每个条目都有一个密集索引条目，这使得搜索索引表或数据库表的 I/O 成本相同，在我看来，这并没有优化我们的 DBMS，我确信我错过了关于密集索引如何工作的一点，但我确实搜索了 Oracle 文档，但没有找到对我的问题的适当回应。
好的，我明白了，在非唯一键的情况下使用密集索引，但我真正的问题是如何使用它来获得唯一键的性能？在唯一键密集索引的情况下访问密集索引上的条目和访问数据库条目之间有什么区别，因为它们具有相同数量的条目？

编辑：

在密集索引中，为数据库中的每个搜索关键字创建一条记录。这可以帮助您更快地搜索，但需要更多空间来存储索引记录。在这个索引中，方法记录包含搜索键值并指向磁盘上的真实记录。

Dense indexes definition

【问题讨论】：

什么是密集索引？
实际上，对于 可为空的列，Oracle B-tree 索引不是dense，因为并非所有行都被索引。
与其在理论上苦苦挣扎，不如简单地创建一个只有几 M 行的表，在 ID 上创建一个索引，并将查询 select * from tab where id =1 的性能与从表中选择所有数据的查询进行比较； ) 前者将访问 2-3 个索引块和一个表块，后者将访问大量表块。这是解释吗？
我已经编辑了我的问题，以便包含一个密集的索引定义@WernfriedDomscheit。
@MarmiteBomber，我会这样做，但实际上我想要的是理解这个概念，我知道使用索引会优化性能，但我想知道如何做到这一点。跨度>

标签： sql database oracle indexing

【解决方案1】：

关键是索引和表是不一样的。

Indexes and Index-Organized Tables

索引是一种可选结构，与表或表簇相关联，有时可以加快数据访问速度。通过在表的一个或多个列上创建索引，您可以在某些情况下从表中检索一小组随机分布的行。 索引是减少磁盘 I/O 的众多方法之一。

索引是逻辑上和物理上独立于与其关联的对象中的数据的架构对象因此，可以删除或创建索引而不会物理影响索引的表。

因此，在 unqiue 索引的上下文中，从单列 B-Tree 索引读取比包含多列的表要快得多。

【讨论】：

在访问单个列条目的情况下查找会更快，但是从数据库中获取数据将与我们将获取相同数量的列相同，换句话说，在找到指针值之后对于我们查询的键，我们将访问数据库以加载其他列值，这将是相同的成本......
换一种说法，你有 1MLN 行表，有 20 列，并生成SELECT * FROM tab WHERE col = 1。哪个更快 - 扫描整个表（读取所有数据页）并将其中的 99% 作为不必要的读取丢弃或扫描小索引，查找指针（rowid）并仅读取所需的数据页？
执行此查询：SELECT * FROM tab WHERE col=1 在不存在索引的情况下，查找过程将读取我们表的所有列（20）并验证是否满足条件？它不会只扫描 col 列值，如果值等于 1，它会返回整个条目？

【解决方案2】：

事实上，我们的数据库表上的每个条目都有一个密集索引条目，这使得搜索索引表或数据库表的 I/O 成本相同，

因为我熟悉的索引都是“密集索引”，所以我将使用“索引”来表示，而使用“稀疏索引”来表示其他品种。

这简直是误入歧途。

索引的目的是显着降低读取表的 I/O 成本。索引在概念上是通过存储键的有序列表来实现的。然后可以快速遍历索引结构以找到特定值或在许多情况下找到一系列值。

概念上您可以将索引视为键和二进制搜索的有序列表。然而，实际的实现可能完全不同。最常用的平衡树。更深奥的类型使用哈希码。然后一些类型是特定于特定数据类型的，例如 GIS 索引和全文索引。

索引的一个非常重要的部分是它可以定位具有特定值的特定行。第二个重要部分是 SQL 表表示无序多集（多集只是允许重复值的集）。

如果你把这些放在一起，你会发现稀疏索引真的没有意义，因为没有办法找到不在索引中的值。

这可能指的是表上的聚集索引。聚集索引是一种特定类型的索引，其中基础数据实际上是按索引键排序的（每个表只有一个聚集索引）。作为对聚集索引的空间优化，稀疏存储是有一定意义的。扫描单个页面上的记录的成本通常与降低几级索引深度的成本相当。

我还想指出，“sparse”在 database-talk 中有更常见的用法——那就是稀疏数据。面向列的数据库针对通常具有NULL 值的列进行了优化。但是，我认为“稀疏索引”的这种使用与稀疏数据无关。

【讨论】：