加入性能：甲骨文VS的MySQL

給定查詢還原成形式：加入性能：甲骨文VS的MySQL

select b.field1 
from table_a a 
    inner join table_b b on b.field1 = a.field1 
    left join table_c c on c.field1 = a.field1 
    left join table_d d on d.field1 = b.field1 
    left join table_e e on e.field1 = b.field6 
group by b.field1, 
     b.field2, 
     b.field3, 
     b.field4, 
     b.field5, 

     e.field2, 
     e.field3 
;

有了它是在20秒運行Oracle中的一定量的數據。 Oracle中沒有任何索引。遷移到MySQL查詢不想完成（在幾分鐘內執行）。有問題的每個字段都在MySQL中編入索引。 Explain說明一切都很好。

還沒有工作後，分組字段得到了多列索引。依然沒有。

什麼是MySQL性能仍然存在巨大泄漏的問題？有沒有加快速度的方法？

來源

2012-06-08 user1433877

您是否還可以確認兩個測試中的基礎結構是否相同？ – Sebas

是的，它是一樣的。另外，我把這個字段放在select中，否則它會在Oracle（Pl/SQL）中拋出一個錯誤。只是想盡可能減少查詢。 – user1433877

我的朋友不是所有的表現都跟着索引一起走，還走引擎，緩存，緩衝區等...... – jcho360

Oracle能夠做散列連接和合並連接，MySQL不是。

由於您的表格沒有以任何方式進行過濾，因此散列連接將是執行連接的最有效方式，尤其是如果您沒有任何索引。

對於嵌套循環，即使所有連接字段都編入索引，MySQL需要在循環中從引導表的每個值執行索引查找（每次從根索引頁開始），然後執行表查找檢索記錄，然後爲每個連接的表重複該記錄。這涉及很多隨機查找。

另一方面，散列連接需要掃描較小的表一次（構建散列表），然後掃描較大的表（搜索構建的散列表）。這涉及順序掃描，速度更快。另外，在嵌套循環中，左連接表只能被驅動（在內循環中掃描），而在任一側的散列連接表可以領先（掃描）或驅動（散列後搜索）。這也會影響性能。

MySQL的優化器儘管支持其他引擎缺乏的幾個方便的技巧，但與其他引擎相比，它的能力非常有限，並且當前不支持散列連接或合併連接。因此，如果這樣的查詢在MySQL上很可能會很慢，即使它在相同數據上的其他引擎上速度很快。

來源

2012-06-08 17:50:51 Quassnoi

有沒有辦法用MySQL來實現這一點？ – user1433877

@ user1433877：實現什麼，散列連接？ No. – Quassnoi

+1但是除了散列表之外，有沒有辦法可以制定解決方法？ – user1433877

加入性能：甲骨文VS的MySQL

回答

相關問題