一个用户迁移数据库前后的性能差异case

标签: MySQL优化设计 ECS optimizer_search_depth RDS | 发表时间:2014-11-23 20:54 | 作者:OurMySQL
出处:http://ourmysql.com

   一个用户工单:数据从ECS迁移到RDS,相同的语句,查询性能下降了几十倍。而实际上RDS这个实例在内存上的配置与原来ECS上的实例相当。

   本文简单说明这个case的原因及建议。

   用户反馈性能变慢的语句为 (修改了真实表名和列名)

   select count(1) from HR hr join H h on h.hid = hr.hid

   join A e on e.aid = h.eid

   join A t on t.aid = e.pid

   join A c on c.aid = t.pid

   join A p on p.aid = c.pid

   left join U u on u.uid = hr.uId

   left join E emp on emp.eid = hr.oid

   where ( hr.s in (1,2,3,4) and hr.cn = 0 );

    背景

   MySQL执行语句过程中涉及到两大流程:优化器和执行器。其中优化器最主要的任务,是选择索引和在多表连接时选择连接顺序。在这个case中,join顺序的选择影响了执行性能。

   确定join执行顺序就需要估算所有join操作的代价。默认配置下MySQL会估算所有可能的组合。

   MySQL Tips: MySQL里限制一个查询的join表数目上限为61.

   对于一个有61个表参与的join操作,理论上需要61!(阶乘)次的评估。当然这是最坏情况下,实际上减枝算法会让这个数字看起来稍微好一点,但是仍然很恐怖。

   在多表join的场景下,为了避免优化器占用太多时间,MySQL提供了一个参数 optimizer_search_depth 来控制递归深度。

   这个参数对算法的控制可以简单描述为:对于所有的排列,只取前当前join顺序的前optimizer_search_depth个表估算代价。举例来说,20张表的,假设optimizer_search_depth为4,那么评估次数为20*19*18*17,虽然也很大(因此我们特别不建议这么多表的join),比20!好多了。

   于是optimizer_search_depth的选择就成了问题。

   MySQL Tips: MySQL中optimizer_search_depth默认值为62.也就是说默认为全排列计算。

   这样能够保证得到最优的执行计划,只是在有些场景下,决定执行计划的时间会远大于执行时间本身。

    量化分析

   在ECS上,是用户自己维护的MySQL,没有设置optimizer_search_depth,因此为默认的62。在RDS上,我们的配置是4。 分析到这里大家能猜到原因是RDS配置的4导致没有得到最优的执行计划。

   下图是optimizer_search_depth=4时的explain结果(隐藏了业务相关的表名、字段名)

    1

   下图是optimizer_search_depth=62是的场景,当然这个case的join表是8个,因此62和8在这里是等效的。

    2

   从图1可以看到,由于optimizer_search_depth=4,优化器认为自己选择了最优的join顺序(22039*1*1*1),优于(41360*1*1*1),而实际上后者才是全局最优。

    关于实践

   可配置的参数提供灵活性的同时,也提出一个头疼的问题:应该设置为多少才合适。 实际上当用户执行一个多表join的时候,对这个语句的整体RT的期望值就不会高。因此可以先定义一个预期,比如优化器决策join顺序的时间不能超过500ms。 用户规格与cpu相关,因此这个只能是建议值。

    用户实践

   实际上更重要的是对于用户来说:

   1) 当出现实例迁移后,多表join执行结果差异较大的时候,要考虑调整这个值。该参数是允许线程单独设置,因此对于应用层来说,每个连接应该都能得到一个较优的值。

   2) 反过来,当设置为默认的optimizer_search_depth=62时,我们我们如何评估我们这个设置是否过大?

   MySQL Tips:MySQL profiling 可以用于查看各执行环节的消耗时间。

   如下是笔者构造的一个60个表join查询的查询,使用profiling查看执行环节消耗的过程。

   set profiling=1;

   set optimizer_search_depth=4;

   explain select …….

   show profile for query 2;

   结果如图

    3

   继续执行

   set optimizer_search_depth=40;

   explain select …….

   show profile for query 4;

    4

    小结

   1)根据机器配置估算一个可接受的时间,用于优化器选择join顺序。

   2)用profiling确定是否设置了过大的optimizer_search_depth。

   3)业务上优化,尽量不要使用超过10张表的多表join。

   4)PS:不要相信银弹。MySQL文档说明设置为0则表示能够自动选择optimizer_search_depth的合理值,实际上代码上策略就是,如果join表数N<=7,则optimizer_search_depth=N+1,否则选N.

猜您喜欢

相关 [数据库 性能 case] 推荐:

一个用户迁移数据库前后的性能差异case

- - OurMySQL
   一个用户工单:数据从ECS迁移到RDS,相同的语句,查询性能下降了几十倍. 而实际上RDS这个实例在内存上的配置与原来ECS上的实例相当.    本文简单说明这个case的原因及建议.    用户反馈性能变慢的语句为 (修改了真实表名和列名).    MySQL执行语句过程中涉及到两大流程:优化器和执行器.

一个InnoDB性能超过Oracle的调优Case

- - P.Linux Laboratory
年前抽空到兄弟公司支援了一下Oracle迁移MySQL的测试,本想把MySQL调优到接近Oracle的性能即可,但经过 @何_登成 @淘宝丁奇 @淘宝褚霸 @淘伯松 诸位大牛的指导和帮助(排名不分先后,仅按第一次为此CASE而骚扰的时间排序),不断修正方案,最终获得了比Oracle更好的性能,虽然是个特殊场景,但是我觉得意义是很广泛的,值得参考,遂记录于此.

oracle函数之case和decode的用法区别及性能比较

- - BlogJava-首页技术区
   在oracle世界,你可以使用:.     1)case表达式      或者.     2)decode函数. Oracle的DECODE函数功能很强,灵活运用的话可以避免多次扫描,从而提高查询的性能. 而CASE是9i以后提供的语法,这个语法更加的灵活,提供了IF THEN ELSE的功能.

一个GC频繁的Case

- loudly - BlueDavy之技术Blog
前两天碰到一个很诡异的GC频繁的现象,走了不少弯路,N种方法查找后才终于查明原因了,在这篇blog中记录下,以便以后碰到这类问题时能更快的解决. 前两天一位同学找到我,说有个应用在启动后就一直Full GC,拿到GC log先看了下,确实是非常的诡异,截取的部分log如下:. 这个日志中诡异的地方在于每次Full GC的时候旧生代都还有很多的空间,于是去看来下启动参数,此时的启动参数如下:.

Oracle CASE WHEN 用法介绍

- - CSDN博客推荐文章
Oracle CASE WHEN 用法介绍. CASE WHEN 表达式有两种形式. CASE sex WHEN '1' THEN '男' WHEN '2' THEN '女' ELSE '其他' END.

DB2数据库性能优化介绍

- - CSDN博客数据库推荐文章
作者:chszs,转载需注明. 博客主页: http://blog.csdn.net/chszs. 前段时间,我从CSDN得到了这本书《DB2数据库性能调整和优化(第2版)》,这是一本介绍DB2数据库性能调优的书籍,此书覆盖了DB2数据库性能调优所需的全部知识和工具,而且还提供了大量的性能调优的实际案例,颇有一种“一书在手,DB2尽在掌握”的豪情.

浅谈MySQL 数据库性能优化

- - BlogJava-qileilove
数据库是 IO 密集型的程序,和其他数据库一样,主要功能就是数据的持久化以及数据的管理. 本文侧重通过优化MySQL 数据库缓存参数如查询缓存,表缓存,. 日志缓存,索引缓存,innodb缓存,插入缓存,以及连接参数等方式来对MySQL数据库进行优化.   这里先引用一句话,从内存中读取一个数据的时间消耗是微秒级别,而从普通硬盘上读取一个数据是在毫秒级别,二者相差3个数量级.

数据库连接池性能比对

- - 企业架构 - ITeye博客
对现有的数据库连接池做调研对比,综合性能,可靠性,稳定性,扩展性等因素选出推荐出最优的数据库连接池 . NOTE: 本文所有测试均是mysql库.    1:性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0. hikariCP的高性能得益于最大限度的避免锁竞争.

烤鱼铅笔袋:Grilled Fish Pencil Case

- Robert - 爱…稀奇~{新鲜:科技:创意:有趣}
这是各种烧烤和夜啤酒爱好者的最佳装备:烤鱼铅笔袋(Grilled Fish Pencil Case),当然也可以当手袋用,放点文具、尺子或者最爱的化妆品甚至是套套,都能彪悍得炭烧味四射,由不得周围人侧目而视~2480日元一个,从内文中的细部图来看,做工相当不错的说. 亲爱的,这些东西也会对你胃口:.

基于SSD的数据库性能优化

- Sungelina - Hello DBA
NOR和NAND都是闪存技术的一种,NOR是Intel公司开发的,它有点类似于内存,允许通过地址直接访问任何一个内存单元,缺点是:密度低(容量小),写入和擦除的速度很慢. NAND是东芝公司开发的,它密度高(容量大),写入和擦除的速度都很快,但是必须通过特定的IO接口经过地址转换之后才可以访问,有些类似于磁盘.