對於我這種剛剛進入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';
然後查詢下表列的數量和統計資訊收集時間，保證統計資訊的正確性。
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
表有序，並且沒有索引。
各位可以看看下面這個連線有三種連線的區別
這篇文章就到此結束，我的優化生涯才剛剛開始！！
記錄一次java優化過程
昨天乙個朋友問我乙個問題，說他們tomcat伺服器，啟動之後，執行特別慢，特別是第一次訪問，有時要十幾分鐘才有響應。我幫他做了下分析，記錄一下。說到tomcat啟動後執行慢，大家首先想到的是，jsp檔案在首次執行時，系統會將jsp編譯成相應的servlet，所以慢是應該的，第一次執行之後，就不再需要...
記錄一次sql優化查詢
場景 關聯查詢，一張主表關聯4張表進行查詢。主表資料量是16萬，其中被關聯的一張表的數量是6萬。遇到頁面響應速度過慢的情況，首先考慮是否是sql查詢緩慢引起的。第一步開啟mysql的慢查詢日誌 網上教程很多，本篇文章不再贅述 第二步分析慢查詢日誌，這裡要說下分析工具。常用的有兩種，一是mysql自帶...
一次優化記錄
備註 由於隱私 部分使用了偽 偽sql 直接查十點查全部 select from 使用者優惠券表 where 優惠券id in select id from 優惠券表 where 限制 新使用者 and 90天內 總時間40 秒 這裡用exlpain分析 優惠券id是有索引的，但是實際上沒有走索引。...