基本情況： 系統(tǒng)是一個基于web的業(yè)務(wù)系統(tǒng)，以online查詢?yōu)橹鳎瑪?shù)據(jù)更新以批量為主，晚上執(zhí)行。應(yīng)該說系統(tǒng)還不算負(fù)載太大。5-1之后上班的時候客戶反映很慢，察看DB的cpu慢慢長到100%狀態(tài)。服務(wù)基本處于不可用狀態(tài)。i/o wait也挺高的。 經(jīng)檢查，前些天的批量竟然有達(dá)到20多小時才完成，導(dǎo)致次日批量都跑不起來。 打開statspack收集信息 從系統(tǒng)中發(fā)現(xiàn)本應(yīng)該夜間執(zhí)行的批量作業(yè)還在運行。停掉后，rollback做了4個小時！（因為一個transaction中只有一個復(fù)雜的、數(shù)據(jù)量巨大的insert語句) 然后做statspack分析， 系統(tǒng)中存在問題:等待事件較嚴(yán)重,緩存命中率較低, 語句分析： 1、一些大量執(zhí)行update/delete語句竟然沒有建立索引，其實可以建立pk，根據(jù)pk處理。 where中使用常量(引起parse) 2、存在大量這樣的語句： SELECT fieldx FROM Tablesname where trim(ServiceNUM) = 'DDDDDD' - 在ServiceNUM字段上是唯一索引，因為trim就不能使用index(敗筆) --改！ - 使用常量查詢，造成每次查詢都要parse，沒有必要的占用的CPU -- 改！ 3、在批量的存儲過程中， 所有語句基本都是全表掃描！ --- 和開發(fā)人員溝通，需要修改邏輯。改進(jìn)之后效果還是蠻大的。 另外發(fā)現(xiàn)一個問題： 客戶需要的是n百萬用戶數(shù)據(jù)中的活動用戶萬數(shù)據(jù)，他們卻全部把n百萬數(shù)據(jù)從其他系統(tǒng)中收集到自己的系統(tǒng)中，在批量的時候又使用full table scan，性能自然不會好。系統(tǒng)從剛開始設(shè)計的時候就存在隱患。這個問題就需要從長計議了。 修改后，CPU高峰時間基本穩(wěn)定在30-40%之間。 批量基本在2個小時內(nèi)完成。 其實是一個很簡單的系統(tǒng)，但是做到這種樣子，尤其是從設(shè)計到編碼都存在問題。呵呵，說真的，不是在優(yōu)化語句的，而是從頭開始看設(shè)計。