MySQL SQL最佳化：Percona最佳化器真的好嗎？

這是MySQL SQL最佳化分享第2篇，大家都很崇尚MySQL的一個強大分支Percona，真該跟風嗎？

有些時候，還是原配靠譜，小三不一定給力。

我們先看下sar報告：

明顯地，CPU %idle 非常低，粗大事了。我們的警示郵件裡顯示，單條SQL執行時間長達 300秒左右。

原始SQL非常長，這裡就不貼了，但要表述的一個最佳化技巧是，最佳化的第一步，就是格式化 SQL  :-)

我們看下問題SQL的問題部分：

LEFT OUTER JOIN `yy_game_info` `game` ON (`t`.`game_code`=`game`.`game_code`)LEFT OUTER JOIN `yy_company_list` `corp` ON (`t`.`company_id`=`corp`.`company_id`)LEFT OUTER JOIN `yy_sp_game_rel` `sp` ON (`t`.`sp_id`=`sp`.`sp_id`                                          AND `t`.`game_code`=`sp`.`game_code`)WHERE (((t.game_code=game.game_code)        AND (t.company_id=corp.company_id))       AND (corp.is_open=1))

可以發現，ON中的關聯條件與謂詞where存在重複。

雖然在MySQL中，過濾器ON和過濾器where的用法不同，但原則上我們不允許出現條件重複

同樣的SQL在備庫執行時效果還不錯：

但我們到主庫執行，發現驅動表竟然走全表掃，鬱悶。

查看版本時，我們發現：

備庫的版本：5.5.22-log （MySQL原版）
主庫的版本：5.5.28-rel29.1-log （Percona原版）
問題SQL在該版本的Percona最佳化器中無法被自動解析，但在MySQL原版可以

這也引出一個問題，複製環境的主備版本最好一致，至少可以減少DBA troshoting的成本

看到了吧，小三未必蓋得過原配

Good Luck！