MySql相同查詢的不同執行路徑

我有兩臺服務器（linode 3072 vps），一臺（舊）有ubuntu 11.04 + Mysql 5.5.32，另一臺（較新）有centos 6.2。 + Mysql 5.5.36。 My.cnf文件也是一樣的。但是，當我在同一個數據庫上運行相同的查詢（直接導出/導入）時，我從2臺服務器獲得了2個不同的響應時間和執行路徑。MySql相同查詢的不同執行路徑

老一個更快的響應。

1 SIMPLE ch ref PRIMARY,channel_name channel_name 122 const 1 Using where; Using temporary; Using filesort 
1 SIMPLE t ref PRIMARY,channel_id channel_id 4 bcc.ch.channel_id 1554  
1 SIMPLE p ref PRIMARY PRIMARY 4 bcc.t.entry_id 1 Using index 
1 SIMPLE c eq_ref PRIMARY,group_id PRIMARY 4 bcc.p.cat_id 1 Using where

較新的一個響應較慢。

1 SIMPLE ch ref PRIMARY,channel_name channel_name 122 const 1 Using where; Using temporary; Using filesort 
1 SIMPLE p index PRIMARY PRIMARY 8 NULL 25385 Using index; Using join buffer 
1 SIMPLE t eq_ref PRIMARY,channel_id PRIMARY 4 bcc.p.entry_id 1 Using where 
1 SIMPLE c eq_ref PRIMARY,group_id PRIMARY 4 bcc.p.cat_id 1 Using where

最大的不同在於第二步。第一臺服務器使用索引，只需掃描1554行，第二臺服務器使用索引+連接緩衝區，並且必須掃描25385行。有什麼想法嗎？

像這樣的查詢和其他查詢導致某些頁面上新服務器每頁加載的時間增加了幾秒。我使用清漆來爲前端服務，但仍想解決這個問題。

這裏是正在運行

select SQL_NO_CACHE cat_name,cat_url_title, count(p.entry_id) as count 
from exp_categories as c 
join exp_category_posts as p on c.cat_id = p.cat_id 
join exp_channel_titles as t on t.entry_id = p.entry_id 
join exp_channels as ch on ch.channel_id = t.channel_id 
where channel_name IN ('resources') 
AND group_id = 2 
group by cat_name 
order by count desc 
limit 5

來源

2014-02-21 user814584

如果您發佈您的查詢以及相關的表格定義，這將有所幫助。兩個服務器上的字符集和表類型（innodb，...）是否相同？ –

查詢是在原始文章中，並且類型或MyISAM，UTF8一般。由於查詢是針對4個不同的表，我可以發佈defs，但認爲它會變得太長，並且不知道它會如何改變，因爲它們完全相同（我在服務器上運行數據庫導出，數據庫導入另一個，沒有別的）。我只是想弄清楚爲什麼在同一個db +查詢中有兩個不同的執行路徑。 – user814584

對不起，詢問查詢;我編輯了這個問題，讓它更加突出。 group_id是exp_category_posts中的一列嗎？如果是的話，似乎第二優化器認爲它可以使用此列快速減少行數。如果猜測錯誤，請嘗試exp_category_posts上的分析表（http://dev.mysql.com/doc/refman/5.0/en/analyze-table.html）更改內容。 –

在MySQL查詢優化器挑來挑去使用了基於它的索引和表的統計信息索引的SQL。有時候索引的選擇不是最優的，查詢執行是不同的。

我們在我們的數據庫中發現，在當天的某些時刻，MySQL更改了它用於相同查詢的執行路徑。

你可以嘗試

analyze table exp_categories,exp_category_posts,exp_channel_titles,exp_channels ;

這有時會提高執行計劃。或者使用索引提示來確定使用哪些索引。

來源

2014-02-21 19:13:53 noz

工作。這是我應該做的定期/自動化？或者，每當MySQL決定錯誤時我只需要處理這個問題？此外，這是此查詢來自的CMS的一部分，因此很難改變此特定查詢。 – user814584

如果您正在對數據進行大量更改，則可能值得自動化。在大量更新之後做一個好主意。 – noz

我剛剛意識到，因爲我將數據導入新的數據庫，這可能是原因，因爲我從來沒有對原始數據庫進行分析，也沒有問題。 – user814584

MySql相同查詢的不同執行路徑

回答

相關問題