MySQL使用index_merge並相交而不是參考和其中

我有一個查詢，在開發和生產（相同的數據庫，相同的數據）上產生不同的優化器結果。MySQL使用index_merge並相交而不是參考和其中

我的機器上查詢運行在大約爲5ms

對生產的查詢中運行〜300-500ms

唯一的區別我能找到的是該行的EXPLAIN EXTENDED結果（和MySQL版本）：

好的查詢

*************************** 2. row *************************** 
      id: 1 
    select_type: SIMPLE 
     table: activities 
     type: ref 
possible_keys: index_activities_on_is_archived,index_activities_on_equipment_id,index_activities_on_date_completed,index_activities_on_shop_id 
      key: index_activities_on_shop_id 
     key_len: 5 
      ref: const 
     rows: 1127 
    filtered: 100.00 
     Extra: Using where

壞查詢

*************************** 2. row *************************** 
      id: 1 
    select_type: SIMPLE 
     table: activities 
     type: index_merge 
possible_keys: index_activities_on_is_archived,index_activities_on_equipment_id,index_activities_on_date_completed,index_activities_on_shop_id 
      key: index_activities_on_shop_id,index_activities_on_is_archived 
     key_len: 5,2 
      ref: NULL 
     rows: 1060 
     Extra: Using intersect(index_activities_on_shop_id,index_activities_on_is_archived); Using where

我不知道該從哪裏開始調試。這是MySQL版本和生產運行舊數據庫的問題嗎？

我的本地版本5.5.15 生產：5.0.95日誌提前

感謝

來源

2012-04-03 Josh

你可以嘗試運行ANALYZE TABLE更新的統計數據，但我懷疑它是倒在優化器的改進。您也可以在查詢中嘗試使用an index hint來告訴MySQL不要使用index_activities_on_is_archived索引。無論如何，這個指數的低基數可能會對性能造成傷害。我會刪除它。

來源

2012-04-03 19:13:09 nnichols

它最終成爲在生產中被禁用的查詢緩存，這將解決問題。

來源

2012-04-03 19:57:16 Josh

MySQL使用index_merge並相交而不是參考和其中

回答

相關問題