前天又被Oracle坑了一回，客戶那個(gè)慢得跟蝸牛似的查詢把我整懵了。搞到半夜兩點(diǎn)才琢磨明白，今天干脆把優(yōu)化器這玩意兒掰開揉碎了講講。

我是怎么被逼著研究優(yōu)化器的

事情是這樣的：客戶那邊有個(gè)報(bào)表死活跑不出來，頁面上轉(zhuǎn)圈圈轉(zhuǎn)了半小時(shí)。我屁顛屁顛連上數(shù)據(jù)庫，隨手敲了個(gè)explain plan，結(jié)果眼珠子差點(diǎn)瞪出來——Oracle這家伙居然選了個(gè)巨慢的全表掃描！明明有索引大哥！氣得我猛灌兩口冰可樂。

我就納悶了，它腦子里到底咋想的？干脆翻官方文檔查它老底。原來優(yōu)化器干活分三步走：先拆解SQL，再估算成本，憋執(zhí)行計(jì)劃。關(guān)鍵就在第二步成本估算，這貨要是算歪了，全盤皆輸。

折騰出來的10條血淚經(jīng)驗(yàn)

整明白原理后，我拿客戶的爛SQL當(dāng)小白鼠反復(fù)試驗(yàn)，總結(jié)出這些門道：

• 查字典別偷懶：用DBMS_*_TABLE_STATS更新統(tǒng)計(jì)信息，沒這步就跟瞎子摸象似的，實(shí)測能讓速度翻倍
• 綁定變量要命：見過有人寫滿屏幕的where id=123，改寫成where id=:var立馬起飛，優(yōu)化器直接緩存計(jì)劃
• 索引順序別亂排：復(fù)合索引把高篩選率列放前面，order by字段塞進(jìn)索引，磁盤讀寫嘩嘩降
• 函數(shù)索引治硬傷：碰到where upper(name)='XXX'這種，建個(gè)函數(shù)索引直接根治
• 分區(qū)表別虛設(shè)：千萬級(jí)數(shù)據(jù)按月分區(qū)，查詢加個(gè)partition限定，速度從十分鐘壓到十秒內(nèi)
• 強(qiáng)制走線有妙用：/+ INDEX(emp idx_emp_dept) / 這種提示偶爾救命，但別當(dāng)飯吃
• 執(zhí)行計(jì)劃要深挖：不光看cost值，重點(diǎn)盯A-Rows和A-Time，實(shí)際跑起來才見真章
• 參數(shù)開關(guān)要會(huì)擰：optimizer_mode從all_rows切first_rows_n，分頁查詢直接竄天
• 子查詢慎用：把exists改成join多表關(guān)聯(lián)，某條SQL從20秒降到0.8秒
• 別信緩存幻覺：第二次跑飛快可能是緩存作祟，重啟實(shí)例再測才靠譜

實(shí)際干一仗看看效果

就拿客戶那個(gè)崩潰查詢開刀。原計(jì)劃全表掃描450萬行，我在create_date列補(bǔ)了統(tǒng)計(jì)信息，又建了個(gè)(status,create_date)的復(fù)合索引。explain plan再一看，樂了——索引范圍掃描，成本值從9863暴跌到37！實(shí)際執(zhí)行直接從28分鐘干到9秒，客戶發(fā)來三個(gè)大拇指表情。

不過也翻過車：有次手賤在所有字段建函數(shù)索引，結(jié)果ｉｎｓｅｒｔ慢成狗。吃一塹長一智，索引這玩意兒多了也壞事。

現(xiàn)在每次調(diào)SQL我都當(dāng)破案：先抓執(zhí)行計(jì)劃，再看統(tǒng)計(jì)信息更新日期，檢查where條件能不能用索引。這套組合拳下來，起碼少加一半班。

對(duì)了，朋友公司吃過更狠的虧——他們DBA忘更新統(tǒng)計(jì)信息，Oracle選了錯(cuò)索引，促銷活動(dòng)時(shí)數(shù)據(jù)庫直接崩了。血淋淋的教訓(xùn)兄弟們！把這些小技巧揣兜里，起碼能少挨點(diǎn)揍。