MySQL SQL优化:Percona优化器真的好吗?

本文通过分析MySQL和Percona版本在处理特定SQL查询时的不同表现,揭示了性能优化策略的重要性。通过对比CPU使用率、SQL执行效率及版本特性,指出主备库版本一致性对于稳定性和性能提升的价值。实例展示了SQL优化策略的有效性,强调了格式化SQL、避免条件重复等最佳实践。
摘要由CSDN通过智能技术生成

这是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!

<!-- Baidu Button BEGIN --&gt <

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26515977/viewspace-1208267/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/26515977/viewspace-1208267/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值