oracle优化器优化步骤详解？10个秘诀快速上手

前天又被Oracle坑了一回，客户那个慢得跟蜗牛似的查询把我整懵了。搞到半夜两点才琢磨明白，今天干脆把优化器这玩意儿掰开揉碎了讲讲。

我是怎么被逼着研究优化器的

事情是这样的：客户那边有个报表死活跑不出来，页面上转圈圈转了半小时。我屁颠屁颠连上数据库，随手敲了个explain plan，结果眼珠子差点瞪出来——Oracle这家伙居然选了个巨慢的全表扫描！明明有索引大哥！气得我猛灌两口冰可乐。

我就纳闷了，它脑子里到底咋想的？干脆翻官方文档查它老底。原来优化器干活分三步走：先拆解SQL，再估算成本，憋执行计划。关键就在第二步成本估算，这货要是算歪了，全盘皆输。

折腾出来的10条血泪经验

整明白原理后，我拿客户的烂SQL当小白鼠反复试验，总结出这些门道：

• 查字典别偷懒：用DBMS_*_TABLE_STATS更新统计信息，没这步就跟瞎子摸象似的，实测能让速度翻倍
• 绑定变量要命：见过有人写满屏幕的where id=123，改写成where id=:var立马起飞，优化器直接缓存计划
• 索引顺序别乱排：复合索引把高筛选率列放前面，order by字段塞进索引，磁盘读写哗哗降
• 函数索引治硬伤：碰到where upper(name)='XXX'这种，建个函数索引直接根治
• 分区表别虚设：千万级数据按月分区，查询加个partition限定，速度从十分钟压到十秒内
• 强制走线有妙用：/+ INDEX(emp idx_emp_dept) / 这种提示偶尔救命，但别当饭吃
• 执行计划要深挖：不光看cost值，重点盯A-Rows和A-Time，实际跑起来才见真章
• 参数开关要会拧：optimizer_mode从all_rows切first_rows_n，分页查询直接窜天
• 子查询慎用：把exists改成join多表关联，某条SQL从20秒降到0.8秒
• 别信缓存幻觉：第二次跑飞快可能是缓存作祟，重启实例再测才靠谱

实际干一仗看看效果

就拿客户那个崩溃查询开刀。原计划全表扫描450万行，我在create_date列补了统计信息，又建了个(status,create_date)的复合索引。explain plan再一看，乐了——索引范围扫描，成本值从9863暴跌到37！实际执行直接从28分钟干到9秒，客户发来三个大拇指表情。

不过也翻过车：有次手贱在所有字段建函数索引，结果ｉｎｓｅｒｔ慢成狗。吃一堑长一智，索引这玩意儿多了也坏事。

现在每次调SQL我都当破案：先抓执行计划，再看统计信息更新日期，检查where条件能不能用索引。这套组合拳下来，起码少加一半班。

对了，朋友公司吃过更狠的亏——他们DBA忘更新统计信息，Oracle选了错索引，促销活动时数据库直接崩了。血淋淋的教训兄弟们！把这些小技巧揣兜里，起码能少挨点揍。