虽然干了很多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倍 |