记某XXB系统一次性能优化
虽然干了很多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倍 |