企业官网建设流程全解析

做了这么多年Oracle数据库运维，被同事问得最频繁的问题之一就是：“怎么看某张表的索引？”乍一听好像很简单，用PL/SQL Developer选中表名，展开目录树，索引分类下面列了一堆名字。但要真讲清楚“这张表到底有哪些索引、索引建在哪些列上、列的顺序是什么、索引当前是否失效、以及SQL执行时到底有没有踩中这个索引”，光靠图形工具那点信息，差了十万八千里。

“Oracle查看指定表的索引”这件事，往小了说是一条SQL的事，往大了说能牵扯出索引失效、统计信息过期、执行计划偏差、甚至整个数据库性能治理的链条。这篇内容我不打算只丢一句select * from user_indexes where table_name='XXX'就收工，而是从最基础的视图查询讲起，结合我实际处理过的案例，把索引查看的完整思路、常用SQL模板、GUI工具的局限性、以及日常巡检时的个人经验全部翻出来，适合刚接触Oracle的开发，也适合想补全索引运维体系的DBA。

1. 为什么总有人问“怎么看Oracle指定表的索引”

1.1 场景比语法更重要：你查索引到底想解决什么问题

我复盘过很多次被问索引查询的场景，发现大家问出这句话时，背后往往藏着一个更具体的诉求。

最常见的场景是SQL变慢了，开发同事怀疑缺索引，但又不确定表上是否已经存在可能被利用的索引，于是先查一下。这类人需要的不仅是索引列表，还需要索引列顺序、索引类型、是否唯一这些信息，用来对照SQL的where条件和join条件。

另一个常见场景在DBA这边：某张历史表一直在膨胀，或者准备归档数据，需要评估表上的索引是否还有保留价值。这时候光看索引存在与否不够，你还得知道索引占了多少空间、最近有没有被使用过、以及如果删掉它会不会影响统计信息或约束。

还有一类场景是数据库迁移或表结构重构。把一张表从一个库搬到另一个库时，索引信息必须一并梳理清楚，特别是函数索引、位图索引这些容易漏掉的特殊类型。只看名字很难判断索引的本质，必须结合索引类型和表达式信息去甄别。

这三种场景对应了三个层次的查询需求：第一层，知道表上有哪些索引；第二层，知道每个索引的字段构成和状态；第三层，知道索引是否可用、是否被使用、是否值得保留。后面所有内容都围绕这三个层次展开。

1.2 查索引背后真正考验的是数据字典的熟悉程度

Oracle里索引的元数据放在数据字典里，最常用的几个视图是user_indexes、user_ind_columns、all_indexes、dba_indexes，另外还有user_ind_expressions、user_constraints、v$object_usage这些辅助视图。很多人查索引只会用其中一个视图，结果要么查漏了函数索引，要么看不清组合索引的列顺序，要么忽略了索引和约束之间的绑定关系。

其实查索引这件事并不难，难的是形成一套完整的查询习惯。比如我看到一张表，第一反应不是直接敲SQL，而是先确定这张表的owner是谁。Oracle里表名允许在不同schema下重复，如果你直接where table_name='ORDER_INFO'而不带owner条件，查出来的可能是别人家schema下的同名表，这种坑我见得不少。

再比如索引状态，user_indexes.status字段有三个常见值：VALID、UNUSABLE、IN_PROGRESS。前两个容易理解，IN_PROGRESS是重建过程中出现的临时状态。如果你查出的索引状态是UNUSABLE，那这索引对执行计划来说基本等于不存在，这才是查询索引时必须第一时间抓住的关键信息。

2. 三大核心视图与标准SQL：从入门到能干活

2.1 user_indexes / all_indexes / dba_indexes到底该查哪个

很多教程一上来就让你查dba_indexes，好像权限不要钱一样。实际上这三个视图的使用场景差异很大。

user_indexes只返回当前登录用户自己schema下拥有的索引。如果你用scott登录，它只显示scott名下的索引，逻辑最简单，也是最不容易出错的起点。all_indexes范围更大一些，返回你当前用户有权限访问的所有schema的索引，只要别人给你授权了表的访问权限，你就能看到对应的索引信息。dba_indexes则是数据库全局视图，能看到所有schema的所有索引，但需要DBA角色或相应的系统权限。

实际工作中我的习惯是：查看当前用户自己的表，用user_indexes；需要排查别人schema下的表，或者做跨schema分析时，用all_indexes并显式指定table_owner；只有做全库级的索引巡检时才会用dba_indexes。把三个视图的权限边界搞清楚，能在很大程度上避免权限报错，也能避免因为查错范围而得出错误结论。

我整理了一张对照表，方便你快速选择：

2.2 先认识user_indexes和user_ind_columns的关键字段

查看索引的SQL想写得顺手，必须先熟悉两个核心视图的字段。

user_indexes这张视图里，我认为最关键的字段有这几个：

• index_name：索引名称，数据库里同一schema下索引名不能重复。
• index_type：索引类型，常见的包括NORMAL（普通B树索引）、BITMAP（位图索引）、FUNCTION-BASED NORMAL（函数索引）、CLUSTER（聚簇索引）、IOT - TOP（索引组织表相关）等。
• table_name：索引所在表的名称。
• table_owner：表的所有者。
• uniqueness：取值UNIQUE或NONUNIQUE，表明该索引是否唯一索引。
• status：索引状态，VALID可用，UNUSABLE不可用。
• tablespace_name：索引所在表空间，判断空间分配时有用。
• last_analyzed：最近一次收集统计信息的时间，排查统计信息过期问题时会用到。

user_ind_columns则是用来查看索引列信息的核心视图，字段比较简单：

• index_name：索引名称。
• table_name：表名。
• column_name：被索引的列名。
• column_position：列在索引中的位置。组合索引中这个字段非常重要，它直接决定索引的匹配规则。比如idx (a,b,c)，a列的位置是1，b是2，c是3，查询时如果只带b列条件，通常用不上这个索引，这就是最左侧前缀原则的基础。

2.3 查询索引的SQL模板：直接抄作业的版本

先给一个最常用、也最能满足日常需求的标准SQL。下面的脚本查询指定表的所有索引，并关联出每个索引包含的列，以及列的位置顺序：

SELECT a.index_name, a.index_type, a.uniqueness, a.status, LISTAGG(b.column_name, ',' ) WITHIN GROUP (ORDER BY b.column_position) AS columns FROM user_indexes a LEFT JOIN user_ind_columns b ON a.index_name = b.index_name WHERE a.table_name = 'ORDER_INFO' GROUP BY a.index_name, a.index_type, a.uniqueness, a.status ORDER BY a.index_name;

这条SQL把索引基本信息和列信息合并成一行，查看的时候非常直观。假设ORDER_INFO表上有三个索引，运行结果大致是：

INDEX_NAME INDEX_TYPE UNIQUENESS STATUS COLUMNS IDX_ORDER_USER NORMAL NONUNIQUE VALID USER_ID,ORDER_STATUS IDX_ORDER_EMAIL FUNCTION-BASED NORMAL NONUNIQUE VALID LOWER(USER_EMAIL) PK_ORDER_ID NORMAL UNIQUE VALID ORDER_ID

注意看第二行，函数索引在user_ind_columns里查不到普通列名，需要到user_ind_expressions视图里看具体的函数表达式。如果你发现某个索引在user_ind_columns对应不上列，十有八九是函数索引。查询方式如下：

SELECT index_name, column_expression FROM user_ind_expressions WHERE table_name = 'ORDER_INFO';

如果是跨schema查看别人的表，只需要把user_indexes和user_ind_columns分别改成all_indexes和all_ind_columns，并在where后面增加a.table_owner = '目标用户名'条件即可。这里有个易错点：all_ind_columns这个视图名不带user_前缀，很多人习惯性写成all_user_ind_columns，结果报ORA-00942表或视图不存在，代码没问题却在拼写上栽跟头。

2.4 索引和主键、唯一约束的绑定关系

查索引时经常被忽略的一个问题是：主键和唯一约束会自动创建索引。这意味着你用drop index去删除一个由约束生成的索引时，大概率会报错，ORA-02429“无法删除用于强制唯一/主键的索引”。

我自己就遇到过类似的场面，开发同学想清理冗余索引，直接从索引列表里看中了PK_ORDER_ID，执行drop index后收到报错，跑来问是不是数据库出了问题。其实处理办法不是删索引，而是先禁用或删除对应的约束：

ALTER TABLE order_info DROP CONSTRAINT pk_order_id;

约束删除后，对应的索引通常会被自动删除。

所以查看指定表的索引时，我建议你同时关注约束信息。下面这条SQL可以快速定位表上的主键约束和唯一约束，以及它们关联的索引名：

SELECT constraint_name, constraint_type, index_name, status FROM user_constraints WHERE table_name = 'ORDER_INFO' AND constraint_type IN ('P', 'U');

查出来之后你会理清一条逻辑链：主键约束通过某个唯一索引来强制，这个索引不能单独删除，必须通过约束操作来处理。只有把索引和约束的关系放在一起看，才算真正掌握了这张表的索引全貌。

3. 完整实操：从建表到索引状态全解读

3.1 准备一张订单表并创建各类索引

空谈理论没有意义，这里我拿一张简化版的订单表来做完整演示。这张表的场景和很多业务系统的订单表类似，包含订单ID、用户ID、商品ID、订单金额、订单状态、用户邮箱、下单时间等字段。

先建表：

CREATE TABLE order_info ( order_id NUMBER(16) PRIMARY KEY, user_id NUMBER(12) NOT NULL, product_id NUMBER(12), order_amount NUMBER(10,2), order_status VARCHAR2(10), user_email VARCHAR2(100), create_time DATE DEFAULT SYSDATE );

这个语句里直接用PRIMARY KEY创建了主键约束，Oracle会自动生成名为PK_ORDER_ID的唯一索引。接着插入一批测试数据，用来模拟真实场景：

INSERT INTO order_info SELECT rownum, MOD(rownum, 1000) + 1, MOD(rownum, 500) + 1, ROUND(DBMS_RANDOM.VALUE(10, 5000), 2), DECODE(MOD(rownum, 3), 0, 'COMPLETED', 1, 'PENDING', 'CANCELLED'), 'user' || (MOD(rownum, 1000) + 1) || '@example.com', SYSDATE - MOD(rownum, 30) FROM dual CONNECT BY LEVEL <= 100000; COMMIT;

数据量不大，十万行，但足够演示索引查看的各种细节。再补几条不同类型索引，覆盖日常和进阶场景：

CREATE INDEX idx_order_user_status ON order_info(user_id, order_status); CREATE INDEX idx_order_email_func ON order_info(LOWER(user_email)); CREATE UNIQUE INDEX uk_order_product ON order_info(order_id, product_id);

这里我建了普通组合索引idx_order_user_status，函数索引idx_order_email_func，以及一个唯一索引uk_order_product。刻意加入函数索引是为了演示如何查看表达式索引，唯一索引则是为了演示uniqueness字段的差异。

3.2 用SQL把这张表的索引底裤翻出来

现在运行前面给过的标准SQL：

SELECT a.index_name, a.index_type, a.uniqueness, a.status, LISTAGG(b.column_name, ',' ) WITHIN GROUP (ORDER BY b.column_position) AS columns FROM user_indexes a LEFT JOIN user_ind_columns b ON a.index_name = b.index_name WHERE a.table_name = 'ORDER_INFO' GROUP BY a.index_name, a.index_type, a.uniqueness, a.status ORDER BY a.index_name;

执行结果中你会同时看到四个索引：主键索引、普通组合索引、唯一索引、函数索引。重点观察两点。

第一，IDX_ORDER_EMAIL_FUNC的index_type字段是FUNCTION-BASED NORMAL，并且它的columns字段是空值，因为user_ind_columns里没有普通列信息。你需要去user_ind_expressions里查它的列表达式，确认索引到底建在哪个函数上。

第二，IDX_ORDER_USER_STATUS的columns字段显示USER_ID,ORDER_STATUS，这个顺序来自column_position排序。如果组合索引顺序反了，比如写成ORDER_STATUS,USER_ID，同一个SQL的优化空间完全不同。

再补充一条查看索引列详细顺序的SQL，适合排查组合索引的列位置：

SELECT index_name, column_position, column_name FROM user_ind_columns WHERE table_name = 'ORDER_INFO' ORDER BY index_name, column_position;

显示结果很清晰地列出每个索引包含哪些列、分别在哪个位置。组合索引的列顺序是SQL优化的核心信息，我通常会把这张小表截图发给开发同事，比口头解释半小时都管用。

3.3 在PL/SQL Developer里的对照操作

我知道肯定有人习惯用PL/SQL Developer的图形界面。操作路径很简单：左侧Tables目录下找到ORDER_INFO表，双击打开表定义面板，切换到Indexes标签页，就能看到索引列表和部分属性。

但这个界面的局限性很明显。它显示的信息止步于索引名、索引类型、唯一性、表空间这些基本内容，不展示组合索引的列顺序，也看不出索引的表达式内容，更不会告诉你索引状态是VALID还是UNUSABLE。

所以我的建议是：图形界面适合快速瞄一眼表有没有索引，一旦需要判断索引可用性、函数索引定义、组合索引列顺序，马上切回SQL查询。两者结合最快，但核心判断依据一定以视图查询结果为准。

3.4 顺便对比一下MySQL的索引查询习惯

网上关于MySQL索引的提问非常多，如果你同时维护Oracle和MySQL两套数据库，会发现两者的索引查看方式差异很大。

MySQL查看指定表索引通常用一条SHOW INDEX FROM语句：

SHOW INDEX FROM order_info;

它返回结果的字段和Oracle有对应关系：Key_name对应index_name，Seq_in_index对应column_position，Non_unique取值为0表示唯一索引对应Oracle的uniqueness='UNIQUE'，Column_name对应column_name。

需要注意的核心差异是：Oracle的组合索引列上限和命名规则与MySQL不完全一致，跨库迁移时如果只搬索引名和表结构，很容易忽略函数索引的表达式差异。更关键的是，Oracle的索引状态有UNUSABLE概念，MySQL一般不会出现类似的逻辑失效状态。这意味着同一套索引维护经验不能直接平移，跨库时要重新审视状态字段。

4. 索引失效与巡检实战：踩过的坑和常用SQL

4.1 一个真实案例：ORA-01502索引失效

有次一个业务系统的报表查询突然报错，错误码是ORA-01502：“索引或这类索引的分区处于不可用状态”。开发同事很着急，把错误信息发过来问怎么回事。

我先让他执行下面的查询：

SELECT index_name, status, tablespace_name FROM user_indexes WHERE table_name = 'REPORT_DETAIL' ORDER BY index_name;

查询结果里有个索引的status是UNUSABLE，问题一目了然。这个索引失效的直接原因是当时批量清理分区数据时，有人对分区做了TRUNCATE操作，某些情况下会导致本地索引或全局索引状态异常。

解决办法是重建索引：

ALTER INDEX idx_report_detail_create_time REBUILD ONLINE;

ONLINE关键字表示在重建过程中允许表上的DML操作继续进行，不至于锁定所有业务请求。如果是大表上的索引，重建前最好先评估一下表空间剩余空间，重建过程中索引段会临时占用额外空间，空间不足会导致重建失败。

这个案例想表达的是：索引失效在Oracle里是真实存在的运维问题，而日常查看索引状态恰恰是发现问题最快的手段。不要等业务报错了才去查索引，定期的状态巡检能把这类风险降到最低。

4.2 怎么知道索引到底有没有被使用

比“看到索引失效”更深一层的需求是：怎么知道一个索引有没有真正被SQL用到。尤其是表上的冗余索引，占了空间但从来不进执行计划，删掉又能节省不少存储。

Oracle提供了一个比较轻量的监控方式，就是v$object_usage视图。它需要你先手动开启某个索引的监控，然后过一段时间再来查看统计结果。

开启监控：

ALTER INDEX idx_order_user_status MONITORING USAGE;

等到业务运行一段时间后，查看监控结果：

SELECT * FROM v$object_usage;

这个视图会返回表名、索引名、是否被使用（USED字段）、监控开始时间等信息。如果USED是NO，说明在监控周期里这个索引没有被任何SQL使用，可以考虑删除或进一步分析。看完之后记得关闭监控：

ALTER INDEX idx_order_user_status NOMONITORING USAGE;

我把这个监控方式用在了很多次索引治理项目里。操作方法不复杂，难点在于监控周期要覆盖业务高峰期，否则监控结果没有代表性。比如你只监控了一个业务低谷时段，某些白天常用的索引在该时段内没有访问，但你不能据此判断它冗余。

4.3 索引健康体检三件套

做数据库日常巡检时，我习惯用五个字概括索引体检关注点：失效、超占、过期。对应的就是三个常见问题：索引不可用、索引段占用空间异常、索引统计信息过期。

第一件套，查全库无效索引。下面的SQL能快速列出所有status不为VALID的索引：

SELECT owner, table_name, index_name, status FROM dba_indexes WHERE status != 'VALID' ORDER BY owner, table_name;

DBA权限普通账号不一定有，如果你只有当前库的访问权限，把dba_indexes换成all_indexes即可。

第二件套，查占用空间最大的索引。大索引往往意味着高存储成本和维护成本：

SELECT segment_name, ROUND(bytes / 1024 / 1024, 2) AS size_mb FROM user_segments WHERE segment_type = 'INDEX' ORDER BY bytes DESC FETCH FIRST 20 ROWS ONLY;

第三件套，查统计信息过期或缺失的索引。统计信息过期会影响优化器对索引成本的判断：

SELECT index_name, table_name, last_analyzed FROM user_indexes ORDER BY last_analyzed NULLS FIRST;

如果last_analyzed是空，或者日期明显早于最近一次大批量数据变更时间，就该重新收集一下统计信息：

EXEC DBMS_STATS.GATHER_INDEX_STATS(USER, 'IDX_ORDER_USER_STATUS');

这三个体检SQL我建议直接存成脚本，每月跑一次，输出结果放到巡检报告里。它们的价值不在于查出多少问题，而在于让索引状态透明化，避免线上系统在最关键的时候给你来一次“惊喜”。

5. 高频问题速查与我的个人经验

5.1 查索引时最常踩的坑

我把这几年工作中被高频问到的问题整理成了一张速查表，先说现象，再给解决方案。

以上每个问题我在实际工作里都遇到过，尤其是表名大小写和同名不同schema这类低级别错误，经常在忙乱时给人头一棒。

5.2 我个人的几个实操习惯

踩过足够多的坑之后，我养成了几个查索引、管索引的习惯，谈不上标准，但确实让工作省心很多。

第一个习惯是命名规范前置。建索引时统一用idx_前缀加表名缩写加字段名缩写的格式，比如idx_order_user_status，一眼就能看出索引建在哪个表的哪些列上。唯一索引用uk_前缀，主键索引由约束自动命名，不用手动干预。规范的好处是查索引时不用费劲猜，看名字就能建立初步判断。

第二个习惯是组合索引字段顺序先问业务需求再拍板。(user_id, order_status)和(order_status, user_id)看着差异不大，实际查询效果天差地别。我的习惯是优先把等值条件的字段放前面，把范围条件的字段放后面，再结合实际SQL的执行计划微调。别拿到字段就建索引，先看看最频繁的查询长什么样。

第三个习惯是定期巡检而不是等到出问题再排查。每个月初我会跑一遍索引状态、索引空间、统计信息这三类SQL，输出结果归档。如果发现某个索引连续三个月USED都是NO，我会主动和业务方沟通是否删除。这种主动式的索引治理，比被动救火舒服得多。

第四个习惯其实最不起眼，但特别实用：每次查索引都带上table_owner条件。哪怕是查当前用户的表，我也会加一行a.table_owner = USER，不为别的，就是为了防止哪天脚本复用的时候因为漏掉owner条件而查错表。

这四个习惯组合起来，基本能保证在“查看指定表索引”这个动作上不出现方向性错误，也为后续的维护和治理打好了基础。