sql - 为什么我们对唯一列使用密集索引？
问题描述
我正在阅读有关 Oracle 数据库索引的内容，但有些地方我无法理解，为什么我们需要密集索引，尤其是在唯一列的密集索引的情况下？事实上，我们的数据库表上的每个条目都有一个密集索引条目，这使得搜索索引表或数据库表的 I/O 成本相同，在我看来，这并没有优化我们的 DBMS，我确信我错过了关于密集索引如何工作的一点，但我真的搜索了 Oracle 文档，但没有找到对我的问题的适当回应。
好的，我明白了，在非唯一键的情况下使用密集索引，但我真正的问题是如何使用它来获得唯一键的性能？在唯一键密集索引的情况下访问密集索引上的条目和访问数据库条目之间有什么区别，因为它们具有相同数量的条目？
编辑 ：
在密集索引中，为数据库中的每个搜索关键字创建一条记录。这可以帮助您更快地搜索，但需要更多空间来存储索引记录。在这个索引中，方法记录包含搜索键值并指向磁盘上的真实记录。
解决方案
事实上，我们的数据库表上的每个条目都有一个密集索引条目，这使得搜索索引表或数据库表的 I/O 成本相同，
因为我熟悉的索引都是“密集索引”，所以我将使用“索引”来表示，而使用“稀疏索引”来表示其他品种。
这简直是误入歧途。
索引的目的是显着降低读取表的 I/O 成本。索引在概念上是通过存储键的有序列表来实现的。然后可以快速遍历索引结构以查找特定值或在许多情况下查找值范围。
从概念上讲，您可以将索引视为键和二进制搜索的有序列表。但是，实际的实现可能会大不相同。最常用的平衡树。更深奥的类型使用哈希码。然后一些类型是特定于特定数据类型的，例如 GIS 索引和全文索引。
索引的一个非常重要的部分是它可以定位具有特定值的特定行。第二个重要部分是 SQL 表表示无序的多重集（多重集只是允许重复值的集）。
如果你把这些放在一起，你会意识到稀疏索引真的没有意义，因为没有办法找到不在索引中的值。
这可能指的是表上的聚集索引。聚集索引是一种特定类型的索引，其中基础数据实际上是按索引键排序的（每个表只有一个聚集索引）。作为对聚集索引的空间优化，稀疏存储是有一定意义的。扫描单个页面上的记录的成本通常与降低几级索引深度的成本相当。
我还想指出，“sparse”在 database-talk 中有更常见的用法——那就是稀疏数据。面向列的数据库针对通常具有NULL值的列进行了优化。但是，我认为“稀疏索引”的这种使用与稀疏数据无关。