一个SQLTuning案例陈宏义-Mooracle.PDF

Meet Mooracle, More Oracle! 一个SQL Tuning的案例 中亦安图 陈宏义 文科生的感叹多 • 在网上订了两次虾爬子，我都因为出差没吃上。 于是就感慨了一下，发了个朋友圈： • 算卦的说，我在上海是吃不上今年春天的虾爬子 了。果然！ • 妈的，我以为是麦子呢。 不食新矣 百度百科 晋景公生病之后，做了一个恶梦。醒来后召桑田巫询问，巫师认为他将 吃不到新麦了。不久，景公病情加重，便向秦国求医。秦桓公派医缓前 来诊治。在医缓来之前，景公又梦到疾病变成二个小孩，一个说：“那 人可是良医呀，恐会伤到我，需要逃跑吗？”另一个则说：“我们在肓 之上，膏之下，他能将我们怎麼样？”医缓来后，直言景公已是病入肓 膏，无法医治（这个故事后来就演变成了成语：病入膏肓）。景公认为 他是良医，并赠以厚礼护送回国。不久，景公想吃麦做的饭，令人献上 新麦，让桑田巫看到新麦，然后将其杀掉。正准备吃饭前感到腹胀，便 去上厕所，但却掉到粪坑中死亡。此时有个宦官梦见自己背着景公登天， 于是在中午由他将景公从茅厕中背出来，并用他来殉葬。 DBA也要算卦– 试一下 DBA也要算卦– 试一下 如果t1只返回一行数据，T2不可能被访问多次，通过算卦， 个人认为是ID 5的cardinality算得不准。 5 - filter (T1.PID=T1.ID) DBA也要算卦– 有枣没枣打一杆子试试 让客户use_hash看一下,结果发现非常快，卦好象算准了 DBA也要算卦– 算卦的也要找Root Cause “T1”.“PID”=“T1”.“ID”这个条件为什么没有算准 Cardinality? 让我们回归到CBO对cardinality的计算方法： DBA也要算卦– 算卦的也要找Root Cause “T1”.“PID”=“T1”.“ID”在CBO计算cardinality的算 法是: NUM_ROWS * (1/greatest(J1.NDV,J2.NDV)) 在本案例中，预估的行数就应该是: 99999*(1/99999) = 1 所以，这是CBO算法的局限，不能算Bug，也不能通过收集统 计信息让他变快。 只算卦不破解是耍流氓– 方案一 如果是两个表连接，cardinality的算法会稍有不同 T1_NUM_ROWS*T2_NUM_ROWS * (1/greatest(J1.NDV,J2.NDV)) 换一种写法: select count(distinct t2.c1) from (SELECT /*+NO_MERGE*/ A.PID , A.ID FROM T1 A, T1 B WHERE A.ID=B.PID) c, t2 where c.pid = t2.pid and c.id=t2.pid; 只算卦不破解是耍流氓– 方案二 decode(t1.id,t1.pid,0,1) 然后收集extended_stats,再改写SQL: select count(distinct t2.c1) from t1,t2 where decode(t1.ID,t1.PID,0,1) 0 and t1.id=t2.id; 只算卦不破解是耍流氓– 方案三 Cardinality hint select /*+cardinality(t1,99999)*/count(distinct t2.c1) from t1,t2 where t1.pid=t2.pid andt1.id=t2.id and t1.pid=t1.id