在生产环境中，Oracle数据库随着数据量增长和业务复杂度提升，经常会出现查询变慢、批处理超时、并发能力下降等问题。性能调优并不是简单地增加内存或CPU，而是要从执行计划、索引设计、统计信息、等待事件等多个维度系统性地排查和改进。只有理解优化器的工作机制，才能用对方法，用最小的改动换取最大的收益。
统计信息与执行计划的关系
Oracle基于成本的优化器（CBO）在生成执行计划时，完全依赖于数据字典中保存的统计信息，例如表的行数、字段的基数、数据倾斜程度等。如果一张订单表在月初有十万行，到了月底变成五百万行，而一直没有重新收集统计信息，优化器仍会认为它很小，从而选择全表扫描而不是索引范围扫描。这种误判是很多性能问题的根源。
手动收集统计信息可以使用DBMS_STATS包，例如对特定表做粒度分析。下面的代码展示了如何对一张业务表收集统计信息，并设定并行度以提升收集效率：
BEGIN
DBMS_STATS.GATHER_TABLE_STATS(
OWNNAME => 'SCOTT',
TABNAME => 'ORDERS',
ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE,
METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO',
CASCADE => TRUE,
DEGREE => 4
);
END;
/
除了手动收集，还应配置自动统计信息收集任务，通常Oracle在夜间维护窗口会运行。但要注意，对于变化极快的表，夜间收集可能仍跟不上白天的写入，此时需要考虑在批处理后主动收集。另外，直方图能帮助优化器识别倾斜数据，比如某个状态字段九成都是已完成，针对未完成状态的查询就应走索引，直方图能让优化器意识到这一点。
索引设计与常见误用
索引是提升查询效率最直接的手段，但建错索引反而拖慢写入并浪费空间。B树索引适合高基数的等值或范围查询，而函数索引则用于解决对列做运算导致索引失效的问题。例如很多开发者写出WHERE UPPER(name) = 'TOM'，若name列只有普通索引，Oracle无法使用它，必须建立函数索引。
组合索引的列顺序非常关键，应遵循最左前缀原则。如果经常按部门编号和入职日期查询，那么(dept_id, hire_date)的索引能同时支持仅按dept_id的查询，但反过来则不行。下面的示例展示了创建组合索引和函数索引的语法：
CREATE INDEX idx_orders_dept_date ON orders(dept_id, hire_date); CREATE INDEX idx_emp_name_upper ON employees(UPPER(last_name));
另一个容易被忽视的问题是索引选择性。对于性别这种只有两三个值的字段，单独建索引通常没有意义，优化器往往选择全表扫描。此时可将其作为组合索引的辅助列，或依靠位图索引在数据仓库场景中处理低基数字段。同时，应定期使用V$SQL_PLAN或AWR报告检查哪些索引从未被使用，将其删除以降低维护开销。
等待事件与系统级调优
当一条SQL变慢，不应只盯着SQL本身，还要看它卡在哪里。Oracle的等待事件接口能精确告诉我们会话在等待什么资源。比如db file sequential read代表单块读，常出现在索引访问中，若等待时间过高说明磁盘IO跟不上；enq: TX - row lock contention则说明应用层有锁竞争。
通过查询V$SESSION_WAIT可以实时抓取异常会话，结合V$SQL定位具体SQL。以下代码列出当前非空闲等待事件的会话及SQL_ID：
SELECT s.sid, s.event, s.wait_time, q.sql_text FROM v$session s LEFT JOIN v$sql q ON s.sql_id = q.sql_id WHERE s.wait_class <> 'Idle' ORDER BY s.wait_time DESC;
在系统层面，共享池和缓冲池的大小设置也会影响性能。如果硬解析比例过高，说明共享池不足或游标未复用，应推动开发使用绑定变量。而缓冲命中率过低，则要考虑增加DB_CACHE_SIZE。但调内存不是万能药，若SQL本身写了笛卡尔积或错误的连接顺序，再大内存也救不了。因此调优顺序应是：改SQL和索引、收统计信息、查等待事件、最后才动参数。
绑定变量与硬解析控制
很多Java或C#程序拼字符串执行SQL，导致每次条件不同都产生新SQL_ID，Oracle被迫硬解析，消耗大量CPU。使用绑定变量后，相同结构的语句可复用游标，显著降低解析开销。但绑定变量窥视（Bind Peeking）在Oracle 11g前可能引发一个问题：第一次解析时用的参数代表性不强，后续所有参数都沿用该计划。
自适应游标共享（ACS）从11g开始缓解了该问题，它允许对同一SQL根据不同绑定值生成多个执行计划。开发中应使用PreparedStatement而非字符串拼接，如下面Java片段所示：
String sql = "SELECT * FROM orders WHERE dept_id = ? AND status = ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setInt(1, 10); ps.setString(2, "OPEN"); ResultSet rs = ps.executeQuery();
对于已上线的旧系统，若无法改代码，可通过设置CURSOR_SHARING=FORCE让Oracle在内部将字面量转为绑定变量，但这可能改变执行计划，需充分测试。总之，稳定的游标复用加上准确的统计信息，是削减CPU使用率最立竿见影的办法。