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

我正在阅读有关Oracle数据库索引的文章，有一点我想不起来，为什么我们需要密集索引，特别是在对唯一列使用密集索引的情况下？事实上，在数据库表的每个条目上都有一个密集索引条目，这使得在索引表或数据库表上搜索的I/O成本相同，在我看来，这并没有优化DBMS的性能，我确信我在密集索引的工作原理上遗漏了一点，但是我确实搜索了Oracle文档，没有找到对我的问题的适当回答。
好吧，我明白了，在非唯一键的情况下使用密集索引的意思，但我真正的问题是，如何使用它来获得唯一键的性能？访问密集索引上的条目与访问唯一键密集索引下的数据库条目有什么区别，因为它们具有相同的条目数

编辑： 在稠密索引中，为数据库中的每个搜索键创建一条记录。这有助于加快搜索速度，但需要更多空间来存储索引记录。在此索引中，方法记录包含搜索键值并指向磁盘上的真实记录。

---

关键的一点是索引与表不同

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

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

所以在unqiue索引的上下文中，从单列B树索引中读取要比从包含多列的表中读取快得多

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

因为我熟悉的索引都是“密集索引”，所以我将使用“索引”来表示这一点，而对于其他种类的索引则使用“稀疏索引”

这完全是误导

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

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

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

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

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

---

我还想指出，“稀疏”在数据库谈话中有一个更常见的用法——那就是稀疏数据。面向列的数据库针对通常具有

NULL

值的列进行了优化。但是，我认为“稀疏索引”的使用与稀疏数据无关。

如果访问单个列条目，查找速度会更快，但从数据库中获取数据与获取相同数量的列相同，换句话说，在找到查询键的指针值之后，我们将访问数据库以加载其他列值，这将是相同的成本…换句话说，您有一个包含20列的1MLN行表，并使

从col=1的选项卡中选择*。哪个更快？扫描整个表（读取所有数据页）并丢弃99%的表作为不必要的读取，或者扫描小索引，查找指针（rowid）并仅读取所需的数据页？执行此查询：
SELECT*FROM tab WHERE col=1
，以防索引不存在，查找过程将读取表中的所有列（20），并验证是否满足条件？它不会只扫描col列值，如果值等于1，它会返回整个条目？什么是稠密索引？实际上Oracle B-tree索引不是空列，因为并非所有行都是indexd。与其与理论抗争，不如简单地创建一个包含少量M行的表，在ID上创建一个索引，并将查询
select*from选项卡（其中ID=1
与从表中选择所有数据的查询的性能进行比较；）前者将访问2-3个索引块和一个表块，后者访问一个表块。这是一种解释吗？我编辑我的问题是为了包含一个稠密的索引定义@WernfriedDomscheit.@MarmiteBomber，我会这样做，但实际上我想理解的是这个概念，我知道使用索引将优化性能，但我想知道如何做到这一点。