MySQL SQL优化:Percona优化器真的好吗
程序员文章站
2022-05-01 23:12:02
...
MySQL SQL优化:Percona优化器真的好吗? 这是MySQL SQL优化分享第2篇,大家都很崇尚MySQL的一个强大分支Percona,真该跟风吗? 有些时候,还是原配靠谱,小三不一定给力。 我们先看下sar报告: 明显地,CPU %idle 非常低,粗大事了。我们的告警邮件里显示,
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!