sql - 表中唯一字段的索引是否允许立即发生选择计数(*)？如果不是，为什么不呢？

Question

我对 SQL 调优的了解足以让自己陷入困境。今天我正在对一个查询执行 EXPLAIN 计划，我注意到它没有使用索引，而我认为它可能应该使用索引。好吧，我一直在对越来越简单(并且在我看来更可索引)的查询上进行 EXPLAIN，直到我对

进行了 EXPLAIN

select count(*) from table_name

我认为这肯定会立即返回，并且解释会显示索引的使用，因为我们在这个表上有很多索引，包括 row_id 列上的索引，它是唯一的。然而，解释计划显示全表扫描，并且需要几秒钟才能完成。 (我们在这个表中有 300 万行)。

为什么 oracle 要进行全表扫描来计算该表中的行数？我想认为，由于 oracle 已经在索引唯一字段，并且必须跟踪该表上的每个插入和更新，因此它将在某处缓存行数。即使不是，扫描整个索引不是比扫描整个表更快吗？

我有两个理论。理论一是我在想象索引如何不正确地工作。理论二是我们的 oracle 设置中某处的某些设置或参数干扰了 Oracle 优化查询的能力(我们在 oracle 9i 上)。谁能赐教一下？

Answer 1

Oracle 不缓存 COUNT(*)。

MySQL 和 MyISAM 可以(负担得起)，因为 MyISAM 是无事务的并且相同的 COUNT(*) 任何人都可以看到。

Oracle 是事务性的，在其他事务中删除的行对于您的事务仍然可见。

Oracle 应该扫描它，看到它已被删除，访问 UNDO，确保它从您的事务的角度来看仍然存在，并将它添加到计数中.

索引 UNIQUE 值与索引非 UNIQUE 值仅在逻辑上不同。

事实上，您可以在定义了非唯一索引的列上创建一个 UNIQUE 约束，并且该索引将用于强制执行该约束。

如果列被标记为非NULL，则对该列的INDEX FAST FULL SCAN 可用于COUNT。

这是一种特殊的访问方法，用于索引顺序不重要的情况。它不遍历 B-Tree，而是按顺序读取页面。

由于索引的页数少于表本身，COUNT 使用 INDEX_FFS 比使用 FULL 更快