nvl本身不使索引失效，但where中对索引列使用nvl（如nvl(status,'n')='p'）会因函数运算导致全表扫描；可通过创建函数索引或拆分条件（status='p' or (status is null and 'n'='p')）优化。
NVL 本身不会让索引失效，但用法不当会绕过索引——关键在 WHERE 条件中是否对索引列施加了函数调用。
为什么 NVL(col, 'X') = 'Y' 会让索引失效
当 NVL 作用于索引列（比如 NVL(status, 'N')）且该列上有普通 B-Tree 索引时，Oracle 无法直接用索引值匹配计算结果，本质等价于对索引列做了函数运算。优化器只能全表扫描后逐行计算 NVL 值再比较。
常见错误写法：
SELECT * FROM orders WHERE NVL(status, 'N') = 'P'; -- status 是索引列，但这里索引不生效
- 即使
status上有索引，这条语句也不会走索引 - 等价于隐式执行
TO_CHAR(status)或CAST，触发函数导致索引跳过 - 尤其在数据中台宽表或历史状态字段上高频出现
用函数索引替代 NVL 表达式
如果业务逻辑必须按 “空值视为某默认值” 查询，最直接的解法是把 NVL 提前固化到索引里，而不是每次查询都算一遍。
创建函数索引：
CREATE INDEX idx_orders_status_nvl ON orders (NVL(status, 'N'));
之后这个查询就能走索引：
SELECT * FROM orders WHERE NVL(status, 'N') = 'P';
- 函数索引只对 Oracle 生效（MySQL/PostgreSQL 不支持同语法）
- 注意：函数索引会增加 INSERT/UPDATE 开销，写多读少的表慎用
- 若
status列为空比例极高，函数索引实际效果可能不如联合索引 + 条件拆分
改写 WHERE 条件，避免在索引列上调用 NVL
多数情况下，NVL 是为了统一空值和非空值的判断逻辑。其实可以拆成两个明确分支，让优化器分别走索引：
SELECT * FROM orders WHERE status = 'P' OR (status IS NULL AND 'N' = 'P');
更实用的写法（适配真实场景）：
SELECT * FROM orders WHERE status = 'P' OR (status IS NULL AND :input_param = 'P');
- 第一支
status = 'P'直接命中索引 - 第二支
status IS NULL在复合索引中若为前导列，也可能走索引（如(status, create_time)） - 避免绑定变量类型不一致引发隐式转换（例如
:input_param是 NUMBER 而 status 是 VARCHAR2）
IS NULL / IS NOT NULL 的索引行为要特别小心
B-Tree 索引默认不存储全 NULL 值，所以 status IS NULL 几乎总是全表扫描。哪怕你建了 NVL(status, 'N') 函数索引，status IS NULL 本身仍不会用它——因为没调用 NVL。
- 想让
IS NULL走索引？得显式在函数索引里覆盖 NULL 场景，比如：CREATE INDEX idx_orders_status_null ON orders (CASE WHEN status IS NULL THEN 'NULL' ELSE status END); - 或者用位图索引（仅限低并发、只读或批量更新场景）
- 联合索引中，
IS NULL只有在前导列固定值的前提下才可能走索引（例如WHERE type = 'ORDER' AND status IS NULL，且索引为(type, status)）
真正容易被忽略的是：函数索引不是“万能胶”，它只对完全匹配其定义的表达式生效；哪怕多一个空格、换一种写法（如 COALESCE 替代 NVL），索引就失效。上线前务必用 EXPLAIN PLAN 验证执行路径。
