今天收到报警邮件，提示在短时间内DB time有了很大的抖动。报警邮件如下：
------------------------------------
而紧接着CPU负载也开始急剧飙升，直接的反应就是机器反应开始非常慢。根据top得到的进程，可以看到cpu资源已经被耗光了。11:30:02 AM CPU %user %nice %system %iowait %steal %idle所以问题其实变得还是挺着急的。这种负载情况下，看似问题还在恶化，着实让人捏了一把汗。top - 13:34:40 up 469 days, 20:09, 6 users, load average: 44.01, 42.83, 43.480.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st根据top的情况抓取了一个进程，看看这个进程到底在干嘛.比如进程号是16908.$ sh showpid.sh 16908查看执行计划的情况如下，其实看计划都是走了索引扫描。$ sh showplan2.sh 7jywxtcmcmcgvPLAN_TABLE_OUTPUT481 | | 155 (1)| 00:00:02 |一边分析一遍生成了一个调优报告。看看dbms_sqltune怎么建议。TASK_68645完整的语句如下：SQL Text : select t0.stat_time stat_time,t2.consume_5cnt给出的建议是创建一个索引。-------------------------------------------------------------------------------查看表的属性情况如下，可以看到当前存在两个索引。*******************************************对于创建索引的如下建议。select column_name,num_distinct,high_value,low_value
,avg_col_len,histogram from dba_tab_col_statistics where
table_name='DY_USER_ANALYSIS_MIN'STAT_TIME 2992 78730C07170101 78730B1B0C3301 8 NONEGAME_TYPE 1 746C6262 746C6262 5 FREQUENCYGROUP_ID 136 C25C44 3E6466 4 FREQUENCY为什么选用了GROUP_ID作为首选列呢，其中一个原因就是范围查询和等值查询，在这个例子中范围查询就是stat_time相关的查询，等值查询就是
group_id相关的。这种情况下是优先选择等值查询的。而game_type的数据分布很单一，所以这个列也不能作为首选列。
可见这个变更也确实起到了立竿见影的效果。但是问题还不止于此，为什么这个语句造成了严重的性能问题，经过后续和开发同事的讨论，他们说这个新需求已经上
线两周了。目前存在大量的left
join的原因就是需要查询这周，上周，上上周。。某一天的数据情况，按照这种思路，其实我还是建议他们去掉这种冗余的left
join,直接使用stat_time in
(xxxx,xxxx,xxxx,xxx）其实这种更简明直接。当然问题解决了还不是结束，还需要后续跟进，保证这种问题从根本上杜绝。
