记录一次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         s
WHERE 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_rows

POLICY_EXTEND_INFO 2012/5/10 0:28:49 140021240
POLICY_VEHICLE_INFO 2012/6/26 0:24:17 144569080
POLICY_SALE 2012/7/2 0:54:23 197587940
POLICY_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_KCI

count(1)

---------

6

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

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

count(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

表有序，并且没有索引。



各位可以看看下面这个连接有三种连接的区别
/article/1449262.html

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