如何查看 Oracle 索引的内容?

发布于 2024-09-14 06:02:28 字数 374 浏览 6 评论 0原文

是否可以使用 SQL*Plus 查看索引内的内容?

如果我有一个像这样的表:

Table A
------------------------
rowid  |  id   name
123    |  1    A
124    |  4    G
125    |  2    R
126    |  3    P

其中 id 是主键,我希望索引是这样的

index on A.id
-------------
id  rowid
1   123
2   125
3   126
4   124

是否有一些 SQL 查询可以使用它来实际查看索引的内容?

Is it possible to have a look at what is there inside an index using SQL*Plus?

If I have a table like this:

Table A
------------------------
rowid  |  id   name
123    |  1    A
124    |  4    G
125    |  2    R
126    |  3    P

where id is the primary key, I expect the index to be something like this

index on A.id
-------------
id  rowid
1   123
2   125
3   126
4   124

Is there some SQL query using which I can actually see the contents of an index?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

回眸一笑 2024-09-21 06:02:28

这不是一个简单的查询 - 您可以将表或索引块转储到跟踪文件,但您必须识别您感兴趣的块。Dion Cho 有一个 示例说明如何使用 SQL 处理此块转储,但这不适合胆小的人。

但是,您可以这样做:

select /* index_ffs (a [name of index]) */
       id, rowid 
  from a
 where id is not null
 order by id, rowid;

Oracle 不会写入所有被索引的值都为空的索引条目,因此如果 id 可为空,我们需要将其过滤掉。 index_ffs 提示强制 Oracle 满足读取索引块而不是数据块的查询。此“解决方案”不显示根或分支块中的数据,而块转储可以。

There's not a simple query - you can dump table or index blocks to trace files, but you have to identify the block you're interested in. Dion Cho has an example of how you can process this block dump with SQL, but it's not for the faint of heart.

However, you can do this:

select /* index_ffs (a [name of index]) */
       id, rowid 
  from a
 where id is not null
 order by id, rowid;

Oracle doesn't write index entries where all of the values being indexed are null, so if id is nullable, we need to filter those out. The index_ffs hint forces Oracle to satisfy the query reading the index blocks, not the data blocks. This "solution" doesn't show the data which would be in root or branch blocks, whereas a block dump can.

最单纯的乌龟 2024-09-21 06:02:28

如果您正在为 EMP_ID 建立索引 - 那么该特定列中的所有值都会被索引
作为叶子 - 例如 B 树 ASC 索引 - 在叶子部分的左侧站点,您应该看到 MIN(indexed_value) 或右侧站点,您应该看到 MAX(indexed_value) - 对于相反的 DESC。
但如果你要求 BRANCHES/ROOT 值,我无法帮助你 - 但总的来说它并不那么重要。
解释计划:

select **min**(emp_id) 
from emp
where emp_id < 100;

select **max**(emp_id) 
from emp
where emp_id < 100;

并将其相互比较(基数 1) - 它只读取一行
来自对象 IND_EMP_ID

and then explain plan for:
select **min**(employee_id), **max**(employee_id) 
from employees 
where employee_id < 100;

--CARDINALITY 40 - 在最小值和最大值之间仅放置索引中的 40 个不同值 - 来自 emp_id 列的所有值。

不要忘记,即使对于 PK,您仍然可以使用 B-TREE/BITMAP INDEX UNIQUE 或 NON-UNIQUE。

If you are indexing EMP_ID - so all values from that particular column are indexed
as leafs - e.g. B-Tree ASC index - on left site of the leafs part you should see MIN(indexed_value) or right site you should see MAX(indexed_value) - for DESC in opposite.
But if you are asking for BRANCHES/ROOT values I can't help you - but in general it is not that important.
explain plan for:

select **min**(emp_id) 
from emp
where emp_id < 100;

select **max**(emp_id) 
from emp
where emp_id < 100;

and compare it to each other (CARDINALITY 1) - it read only one row
from object IND_EMP_ID

and then explain plan for:
select **min**(employee_id), **max**(employee_id) 
from employees 
where employee_id < 100;

--CARDINALITY 40 - between min and max only 40 different values in index are placed - all values from column emp_id.

Do not forget that even for PK you can still using B-TREE/BITMAP INDEX UNIQUE or NON-UNIQUE.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文