雖然幹了很多SQl優化。 也寫博客記錄了很多， 但是貌似沒有記錄過系統整體優化的， 這次簡單記錄下吧。
景
XXB系統作爲核心的應用系統，具有涉及業務領域多，併發訪問量大，累計數據量大等特點。而且隨着市場的變化，尤其是在大數據環境下，數據增量明顯提高。而用戶對性能的要求也進一步提高，給系統性能優化帶來新的挑戰。
分析
在業務人員的大力度支持下，全面瞭解系統的業務特點，性能瓶頸。發現業務高峯期CPU負載壓力過高，一般業務高峯期50%左右，在“結算”“稽查”等業務合算過程中，CPU使用率超過 90%。也通過調查發現IO的吞吐量不高，才6M/S. IOPS也很小。進一步確定到系統壓力在邏輯讀上面。比如我們選取某一典型時間段CPU使用率以及邏輯讀數據曲線圖 .
業務高峯期AWR報告
TOP等待事件中“db file sequential read”最高， 該等待事件一般是和索引掃描(除了index fase full sacn),和索引回表造成的。 這種現象表示需要優化TOP SQL。
TOPSQl分析：(這裏只列出典型的三個)
|
SQL |
執行頻率 |
執行成本 |
|
5b3a7przhx4sc |
5萬次/半小時 |
2萬邏輯讀/次 |
|
55495fd93c886 |
4.4萬次/半小時 |
2.8萬邏輯讀/次 |
|
d0sd7kxr6ga47 |
8千次/半小時 |
4.7萬邏輯讀/次 |
對象分析：
和業務組大力度的交流中發現有些索引碎片非常嚴重，如下
|
索引 |
索引字段 |
索引體積 |
碎片程度 |
|
IDX_STU_O_ID |
STUD_ORDER_ID |
964M |
大約90%的碎片 |
|
INX_EXT_V_PARAM_ID |
PARAM_ID |
1376M |
大約90%的碎片 |
|
PK_ZMKM_ORDER_EXT_VAL |
EXT_VAL_ID |
2744M |
大約90%的碎片 |
|
INX_EXT_VAL |
EXT_VAL |
68M |
大約60%的碎片 |
實施
分別整理系統分析文檔，以及優化建議文檔，和業務組展開深入討論交流後決定實施優化。需要在業務低谷時間實施優化，實施過程中需要保障系統穩定的同時也要保證優化的平滑進行。
優化後：
業務高峯期整體表現：
|
|
優化前 |
優化後 |
|
CPU使用率 |
50%左右，偶爾90%+ |
12%左右，偶爾20%+ |
|
邏輯讀 |
150萬邏輯讀/S,偶爾250萬邏輯讀/S |
50萬邏輯讀/S,偶爾70+萬邏輯讀/S |
|
索引 |
索引字段 |
索引體積 |
重建後體積 |
|
IDX_STU_O_ID |
STUD_ORDER_ID |
964M |
20M |
|
INX_EXT_V_PARAM_ID |
PARAM_ID |
1376M |
104M |
|
PK_ZMKM_ORDER_EXT_VAL |
EXT_VAL_ID |
2744M |
168M |
|
INX_EXT_VAL |
EXT_VAL |
68M |
8M |
TOPSQl分析：
|
SQL |
執行頻率 |
優化前 |
優化後 |
|
5b3a7przhx4sc |
5萬次/半小時 |
2萬邏輯讀/次 |
3千邏輯讀/次，性能提升6倍 |
|
55495fd93c886 |
4.4萬次/半小時 |
2.8萬邏輯讀/次 |
7千邏輯讀/次，性能提升3倍 |
|
d0sd7kxr6ga47 |
8千次/半小時 |
4.7萬邏輯讀/次 |
3200邏輯讀/次,性能提升10倍 |