Oracle 数据库SQL优化指南

一、常见不走索引的情况

在 WHERE 子句中对索引列使用函数或表达式
- 示例：SELECT * FROM employees WHERE UPPER(last_name) = 'SMITH';
- 示例：SELECT * FROM employees WHERE salary * 1.1 > 5000;
  原因：函数或计算会导致索引失效。
对索引列进行隐式或显式类型转换
- 示例：SELECT * FROM employees WHERE phone_number = 1234567;（phone_number 为字符串类型）
  原因：类型转换导致索引无法使用。
使用不等于操作符（<> 或 !=）
- 示例：SELECT * FROM employees WHERE department_id <> 10;
使用前导通配符的 LIKE 查询
- 不走索引：LIKE '%son' 或 LIKE '%son%'
- 走索引：LIKE 'son%'
使用 IS NULL 或 IS NOT NULL
注意：除非是位图索引或索引包含 NULL 值，否则通常不走索引。
使用 NOT IN
建议：尽量改写为 NOT EXISTS 或其他等价形式。

重复索引（如 idx1(col1,col2,col3)、idx2(col1)、idx3(col1,col2)）会占用大量空间，并显著降低 DML 操作性能。优化方案：

分析索引使用情况，删除冗余索引，只保留最优的复合索引。

单个大事务提交时间长，异常时回滚耗时久，不支持断点续跑，容易影响联机业务。优化方案：

根据业务逻辑拆分成多个小事务，阶段性提交，支持断点续跑。

表设置为 NOLOGGING 时，LOB 对象也会跟随，导致并发环境下产生大量 enq: CF - contention 等待，严重影响性能。优化方案：

表和对应的 LOB 对象均设置为 LOGGING。

统计信息 LOW_VALUE 和 HIGH_VALUE 以 NUMBER 形式存储，导致执行计划估算偏差大，SQL 效率低下。优化方案：

统一使用 DATE 或 TIMESTAMP 类型。

建议：表大小超过 10GB 或行数超过 1000万时，建议进行分区。

Keep 在内存中（可选）：sql

复制代码

EXEC DBMS_SHARED_POOL.KEEP('SCHEMA.SEQUENCE_NAME', 'Q');

增加 SQL 与 PL/SQL 引擎切换开销，业务逻辑分散，维护困难，迁移风险高。优化建议：

基础数据操作逻辑尽量放在应用层实现。

包含 UNION/UNION ALL/INTERSECT/MINUS/CONNECT BY/ROWNUM 的视图无法进行视图合并，导致 SQL 效率低下。优化建议：视图定义中尽量避免上述语法。

不使用绑定变量场景：

位图索引锁粒度大，高并发下容易产生大量行锁和死锁。优化建议：OLTP 表一律不使用位图索引。

会导致后续 INSERT 性能急剧下降（Bitmap Block 维护问题）。优化方案：

分批 DELETE + 多次 COMMIT，建议在业务低峰期执行。

复制代码

ALTER TABLE table_name TRUNCATE PARTITION p1 UPDATE GLOBAL INDEXES;

单调递增的序列 + 索引会导致热点块竞争。

优化建议：采用前缀 + 随机序列等方式，避免单向递增。

默认并行度 > 1 时，全表扫描和索引快速全扫描都会并行，消耗大量 CPU 和 IO。优化建议：sql

复制代码

ALTER TABLE t1 PARALLEL 1;
ALTER INDEX idx1 NOPARALLEL;