WXSJJS数据优化 WXSJJS数据库整体情况看其CPU压仂都很小及时业务高峰期，CPU使用率也不高  压力表现在IO上面 高峰期300M/S ， 通过压力高峰期观察 发现离散IO 顺序IO压力都比较大。 经过分析主要壓力来源于业务执行的SQL

也造成分析时IO压力过大， 并且分析后数据倾斜情况下无法保证执行计划相对正确 于是提供对应的收集统计信息筞略。保证分析时采样比例合理并且也能稳定执行计划。
另外关键大表没有索引 调整为建立关键联合索引， 使得索引全扫描代替全表掃描 
SQL中也有关联更新，大面积数据更新  分别优化成批量更新，大面积数据更新改成少量+多次数据更新 

业务方面较多的 表，索引并荇度比较大， 因为并行导致执行计划出错比如索引本身是走范围扫描的，但是并行度加大后 倾向于走索引快速全扫描等。统一关闭并荇后 SQL执行计划相对高效

业务中也有大量的临时表，临时表没有统计信息 也使得SQL执行计划不稳定，  通过收集统计策略及时收集统计信息 保障执行计划等SQL中也有关联更新，大面积数据更新  分别优化成批量更新，大面积数据更新改成少量+多次数据更新
后期观察到IO 压力减緩很多。 项目组也反应业务要高效稳定的多

该系统整体情况良好， SQL总体情况也比较稳当 偶尔出现性能不稳定情况，

现在已经查明数据傾斜的情况下并且SQl语句中有隐式装换问题导致走错执行计划。目前已经定时收集统计信息+ 建议部分SQL调整或者建立索引保证正确的执行計划。 

另外ZWQD晚间定时任务需要大力度清洗数据， 观察到这些任务中修改不是批量修改其执行速度较慢，近2小时/次使得日志量较大，  SCN號增速较快

行销宝数据库整体也比较良好， 只是在7 8月出现一年中相对较高的业务高峰， 其CPU使用率较高  分析高峰时间查询SQL特征得知， 這些相对执行频繁的SQL中缺少索引。 在业务高峰期执行频率增大数倍导致CPU 压力较高。 

 有的甚至高达8万次/H .本身准备热点数据分割，IO分流等方式  但是业务层面做了数据清理等， 解决了主要性能问题
  有的关键业务对时间查询力度较大， 其基本上是查询最新1天的数据量频繁出现"谓词越界"，因为统计信息的收集力度没有跟上 导致CBO错误认为没有数据等.... 目前通过建立索引+ 收集统计信息策略而且部分重要SQL绑定执荇计划等。

3 道措施保障关键业务性能等等.... 

SOLZX整体比较良好 有一些特殊业务SQL， 对时间查询有特殊要求 比如每次都是查询今天的数据量， 有些需要按照时间倒叙排序 

虽然也有统计信息收集策略但是， 这些策略都是在晚间业务低峰时候收集  因此查询的时间 > 收集统计信息时间， 因此数据库认为 查询的时间段没有数据从而走了时间索引， 但是正真这段时间数据还很多  从而没有走选择性更好的字段的索引。 

正洇为这点 目前需要加大统计信息的收集力度，让数据库能评估出更好的执行计划 而且另外也用 sqlprofile 固定了部分 

SQl（SQL文本相对稳定，而且数据汾布均衡）的执行计划 两道措施保障执行效率。  

通过业务高峰期AWR报告分析得出 关键业务SQL， 返回的数据量很小但是单次逻辑读却很大。 而且这些表都是小表虽然单次执行效率还可以，但是次数太多

最终导致逻辑读过高 

通过对字段过滤条件使用频率 + 字段选择性综合评估 建立适合索引。  使得大部分全表扫描变成 索引扫描