记录一次sql优化过程

对于我这种刚刚进入DBA行业的人来说sql优化是一件很难的事情。所以今天看了一下别人优化的过程顺手记录的一笔。

SELECT DISTINCT vi.policy_no  FROM odsdata.policy_extend_info  ei,       policy_vehicle_info vi,       policy_base_info    bi,       odsdata.policy_sale         sWHERE ei.policy_no = vi.policy_no       AND bi.sale_no = s.sale_no       AND bi.policy_no = vi.policy_no       AND ei.quote_user_id = 'SHXT-00014'       AND s.key_customer_id = 'SANY';

上面的就是要优化的sql。下面把统计信息拿出来

然后查询下表列的数量和统计信息收集时间，保证统计信息的正确性。

SELECT table_name,last_analyzed,num_rows FROM Dba_Tables   WHERE table_name IN('POLICY_VEHICLE_INFO','POLICY_EXTEND_INFO','POLICY_BASE_INFO','POLICY_SALE');table_name         last_analyzed       num_rowsPOLICY_EXTEND_INFO 2012/5/10 0:28:49 140021240POLICY_VEHICLE_INFO 2012/6/26 0:24:17 144569080POLICY_SALE 2012/7/2 0:54:23 197587940POLICY_BASE_INFO 2012/4/27 2:16:05 159532440

一看都是上亿的数据，这样的数据查询起来如果没有索引，而走全部扫描的话估计就得慢死。所以查询条件必须全部走索引！！而且统计信息收集得也有点老了！！所以下一步就查询下所有的列是否有收集统计信息，是否有索引等。

SELECT COUNT(1) FROM odsdata.policy_sale s WHERE s.key_customer_id = 'SANY'; -- IDX_PS_KCIcount(1)---------6

明显看出走的索引，而且数据量不大

SELECT COUNT(1) FROM odsdata.policy_extend_info  ei WHERE ei.quote_user_id = 'SHXT-00014';--IDX_PEI_QUIcount(1)---------6

明显看出走的索引，而且数据量不大

根据原始的sql语句我抽取了其中的一部分来查看

SELECT COUNT(1) FROM odsdata.policy_sale s,policy_base_info    bi  WHERE s.key_customer_id = 'SANY'  AND bi.sale_no = s.sale_no;

这条语句执行很慢，所以我估计问题就出在这里了！！看下统计信息

这里用了一个hash join而原始的查询没有用到索引，索引在这里加上了一个hints./*+ index(bi inx_pol_base_sale)*/

加了索引后表POLICY_BASE_INFO开始走索引了

然后同事直接加入hints让oracle走嵌套循环，这一步我还有点不明白，所以我的好好的看看各个连接的区别。

表之间的关联有如下三种方式：

（1）    Nested Loop

Inner table 循环与outer table匹配，这种是表有索引，选择性较好，表之间的差距不大。 ===》两层for 循环，小表匹配大表。

（2）    Hash John

小表做hash ，放内存，然后拿大表的每条记录做hash，然后与之前小表的Hash 值匹配。==》大表匹配小表。

（3）    Sorted Merge Into

表有序，并且没有索引。

各位可以看看下面这个连接有三种连接的区别

http://blog.csdn.net/tianlesoftware/article/details/5826546

 

这篇文章就到此结束，我的优化生涯才刚刚开始！！