干了十来年Oracle DBA，最常被问到的不是怎么装库，也不是怎么搭RAC，而是“这SQL怎么又慢了”。这话听着简单，背后全是血泪。索引建了，统计信息也收了，执行计划看着挺顺眼，可一到业务高峰，响应时间照样飙到让人心梗。说白了，性能调优这活儿，三分靠工具，七分靠思路，剩下九十分全靠踩坑。今天不整那些虚头巴脑的理论，就聊聊我在生产环境里真正用过的五大核心策略，每一条都是拿事故换来的。
先讲第一个策略，也是最容易被忽略的：从等待事件入手，而不是盯着CPU使用率看。很多刚入行的兄弟一看CPU飙到90%就慌，急着加硬件、调参数，结果钱花了问题还在。实际上，Oracle的等待事件才是真正的病根子。比如你看到大量“db file sequential read”，那八成是索引扫描出了问题；如果是“enq: TX - row lock contention”，那就是锁等待在捣鬼。我去年处理过一个案子，某核心系统每天下午三点准时卡死，CPU利用率不到30%，但业务就是提交不了。一查AWR，发现“log file sync”排在等待事件第一位，原来是提交频率太高，redo日志写不过来。后来把批量提交改成每500条一次，问题直接消失。记住，调优前先看v$sessionwait和v$systemevent，让数据告诉你瓶颈在哪，别瞎猜。
第二个策略，执行计划不能只看一眼就完事，得学会“反推”。什么叫反推？就是拿着实际返回的行数和执行计划里预估的行数对比。Oracle的CBO再聪明，也得靠统计信息吃饭，统计信息一失真，执行计划就变成空中楼阁。我见过最离谱的情况，一张1.2亿行的分区表，统计信息显示只有3000行，优化器愣是选了个全表扫描，每次查询跑40多秒。后来重建统计信息，同样的SQL变成0.3秒。所以调优的时候，别光盯着执行计划里的cost值，要重点看Rows那一列，如果预估行数和实际行数差了两个数量级以上，赶紧查表的分区裁剪、直方图、采样比例这些细节。有时候一句简单的“exec dbmsstats.gathertablestats”就能救你于水火。
第三个策略，索引这东西，不是越多越好，而是越“准”越好。很多开发人员有个误区，觉得给表的每个字段都建上索引就万事大吉。结果呢？索引倒是建了一堆，每次DML操作要维护的索引比数据本身还多，查询时优化器还得在一堆索引里挑来挑去，挑错了就是灾难。我调优时有个习惯，先看SQL的WHERE条件里的等值查询、范围查询、排序字段，再结合实际的业务访问模式去设计复合索引。比如有个订单查询，经常用“状态+创建时间”过滤，那就建个(状态,创建时间)的复合索引，把选择性高的字段放前面。但别走极端，索引列数超过三个就要慎重了，否则索引本身比表还大，扫描索引的成本可能比全表扫描还高。还有，定期用index monitoring去查哪些索引压根没被用过，该删就删，别舍不得。
第四个策略，SQL改写往往比任何参数调整都管用。有些SQL写得那叫一个“艺术”，嵌套子查询套了三层，UNION ALL和UNION混着用，还带了一堆函数包裹在索引列上。比如你在WHERE条件里写了“WHERE TOCHAR(createdate,'YY-MM-DD') = '2024-01-01'”，那索引就废了，因为函数破坏了索引列本身的值。改成“WHERE createdate >= TODATE('2024-01-01','YY-MM-DD') AND createdate < TODATE('2024-01-02','YY-MM-DD')”，范围扫描直接走索引，效果立竿见影。还有那种“NOT IN”子查询，很多时候改成“NOT EXISTS”性能能提升好几倍，因为NOT IN会做全量匹配，而NOT EXISTS只要找到一个就停。调SQL别怕麻烦，拿DBMSXPLAN.DISPLAYCURSOR把实际执行计划拉出来，一行行看，哪里出现SORT、HASH JOIN、FILTER，哪里就是优化点。
第五个策略，内存和I/O层面的调优，得放在做。为什么？因为这是最贵的，也是风险最大的。很多DBA一上来就调SGA、PGA，把内存调大，看起来性能提升了一点，但治标不治本。我见过一个系统，SGA从8G调到32G，刚开始确实快了，跑了两个月后反而更慢了，原因就是Buffer Cache太大，导致DBWR进程频繁写盘，I/O压力反而增加。真正该做的是看v$bufferpoolstatistics，算一下Buffer Cache命中率，如果低于95%再考虑增大DBCACHESIZE。还有PGA，如果sortarea_size设得太大，大量排序在内存里完成，但内存不够时就会疯狂用临时表空间，这时候优先优化SQL里的排序和分组逻辑，而不是直接加内存。记住，先优化代码，再调内存，才考虑加存储或换硬件。
说个真实案例把这五个策略串起来。某银行核心报表系统，每月末跑批要花6个小时，业务部门天天催。我接手后没急着调，先抓了一个小时的AWR报告，发现“direct path read temp”排第一，临时表空间使用量飙升。再一看SQL，有个统计报表用了个三层嵌套子查询，中间层还带了个大表的全表扫描。我先用策略二反推执行计划，发现统计信息严重过期，重新收集后执行计划变了，但还不够快。接着用策略四改写SQL，把子查询里的重复扫描部分用WITH子句抽出来，临时表空间使用量直接降了70%。用策略三调整索引，把原来两个单列索引合并成一个复合索引，跑批时间从6小时缩短到47分钟。全程没动过任何内存参数，策略一和策略五基本没用上，因为问题根本不在等待事件和内存上。
所以你看，Oracle性能调优这事儿，核心不是你会用多少工具，而是你能不能按正确的顺序排查问题。等待事件告诉你表象，执行计划告诉你逻辑，统计信息告诉你真相，SQL改写和索引设计才是真正的功夫。这五大策略，说穿了就是一套排查方法论：先看现象，再查计划，然后改SQL，动资源。每一步都得用数据说话，别拍脑袋。你要是能把这套思路变成肌肉记忆，那不管换到哪个数据库环境，都能快速找到症结所在。调优这件事，永远没有“最好”，只有“更合适”。今天这篇聊的是五大核心策略，但真正的实战里，每个策略背后还有无数细节等着你去抠。
