oracle pl/sql本身不利用索引，真正起作用的是sql执行时优化器对索引的选用；能否走索引取决于sql结构、字段是否被索引、统计信息准确性及绑定变量值的可选择性。
Oracle PL/SQL 本身不“利用索引”，真正起作用的是 SQL 执行时优化器对索引的选用；PL/SQL 只是承载 SQL 的容器。能否走索引、走哪个索引，取决于你写的 SQL 语句结构、字段是否被索引、统计信息是否准确，以及运行时绑定变量值的可选择性。
为什么明明写了 WHERE 条件，却没走索引？
常见现象：SQL 看起来完全合理，EXPLAIN PLAN 却显示 FULL TABLE SCAN，甚至 INDEX FULL SCAN 都没出现。
- 索引列上用了函数或表达式，比如
WHERE UPPER(name) = 'ABC'→ 改用函数索引或提前标准化存储 - 隐式类型转换，比如
WHERE order_id = '123'（order_id 是 NUMBER）→ 字符串常量触发隐式转 NUMBER，但索引列实际是 NUMBER 类型，可能导致索引失效 - 谓词条件未覆盖索引最左前缀，例如索引是
(status, create_time, user_id)，但查询只写WHERE user_id = ?→ 无法利用该索引 - 优化器估算返回行数太多（比如 >5% 表数据），认为全表扫描成本更低 → 此时加
/*+ INDEX(t idx_name) */提示可能强行走索引，但需验证 buffer gets 是否真下降
怎么确认某个查询到底走了哪个索引？
不能只看 PL/SQL Developer 工具栏里“执行计划”按钮的结果——它默认用绑定变量空值或默认值解释，和真实执行路径可能不一致。
- 在真实会话中执行后立即查
V$SQL_PLAN：SELECT operation, options, object_name, filter_predicates, access_predicates FROM v$sql_plan WHERE sql_id = 'your_sql_id' AND child_number = 0 ORDER BY id;
-
access_predicates显示哪些条件真正用于定位索引行（如"STATUS"='ACTIVE'）；filter_predicates是回表后才过滤的（说明索引没覆盖这部分） - 结合
DBMS_XPLAN.DISPLAY_CURSOR查真实执行时的 A-Rows（实际返回行数）和 Buffers（逻辑读），比看预估 Cost 更可靠
覆盖索引怎么建才真正免去回表？
不是“把所有 WHERE 列塞进索引”就叫覆盖，关键是要覆盖 SELECT 列 + WHERE 条件列 + ORDER BY / GROUP BY 列（如果不需要排序/分组，可省略）。
- 错误示范：
CREATE INDEX idx_orders_1 ON orders (user_id) INCLUDE (amount)→ Oracle 不支持INCLUDE语法（那是 SQL Server 的） - 正确写法：
CREATE INDEX idx_orders_cover ON orders (user_id, create_time, status, amount)，对应查询：SELECT status, amount FROM orders WHERE user_id = ? AND create_time > ?
- 注意顺序：等值条件列（
=、IN）放最左，范围条件列（>、BETWEEN）放中间，SELECT 列放最后；否则范围之后的列无法用于索引查找
高并发 OLTP 下，索引越多越好吗？
不是。每个索引都是双刃剑：读快了，写就慢了，而且并发越高，争用越明显。
- INSERT/UPDATE/DELETE 每修改一行，所有相关索引都要同步更新 → 多一个索引，就多一次
db file sequential read和 latch 获取 - 索引段本身也参与缓存竞争，大量小索引容易挤占 buffer cache，反而让热数据被踢出
- 特别警惕“伪唯一索引”：比如给
email建了普通索引，但业务层没做唯一性校验 → 既没发挥唯一约束价值，又承担了全部索引维护开销 - 定期用
SELECT index_name, leaf_blocks, distinct_keys FROM user_indexes WHERE table_name = 'YOUR_TABLE'看索引大小和离散度，长期distinct_keys接近 1 的索引，大概率已失效
真正卡住性能的，往往不是“有没有索引”，而是“索引能不能避免回表 + 统计信息准不准 + 绑定变量窥探是否生效”。别急着建新索引，先跑一遍 DBMS_STATS.GATHER_TABLE_STATS，再看执行计划里 A-Rows 和 E-Rows 是否接近——差十倍以上，基本就是统计信息拖了后腿。
