相同sql不同机器上效率差异case有哪些
这篇文章将为大家详细讲解有关相同sql不同机器上效率差异case有哪些,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。
“只有客户发展了,才有我们的生存与发展!”这是创新互联公司的服务宗旨!把网站当作互联网产品,产品思维更注重全局思维、需求分析和迭代思维,在网站建设中就是为了建设一个不仅审美在线,而且实用性极高的网站。创新互联对成都做网站、网站制作、网站制作、网站开发、网页设计、网站优化、网络推广、探索永无止境。
一个用户问题,数据从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结果(隐藏了业务相关的表名、字段名) 下图是optimizer_search_depth=62是的场景,当然这个case的join表是8个,因此62和8在这里是等效的。 从图1可以看到,由于optimizer_search_depth=4,优化器认为自己选择了最优的join顺序(22039*1*1*1),优于(41360*1*1*1),而实际上后者才是全局最优。 有趣的是,在这个case里面如果多看一层,就能得到最有解,因为第一个join顺序的第五个表评估rows为82720。 这意味着,在这个case里面,设置为5与设置为62能得到相同的执行计划,当然设置为5时的优化器执行代价更小。这其实也就是提供optimizer_search_depth的本意:减少优化器执行时间,而且概率上还存在局部最优就是全局最优解的情况。
关于实践
可配置的参数提供灵活性的同时,也提出一个头疼的问题:应该设置为多少才合适。
实际上当用户执行一个多表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; 结果如图 继续执行 set optimizer_search_depth=40; explain select ....... show profile for query 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. 多表连接的参数
关于“相同sql不同机器上效率差异case有哪些”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,使各位可以学到更多知识,如果觉得文章不错,请把它分享出去让更多的人看到。
文章题目:相同sql不同机器上效率差异case有哪些
网站URL:http://hbruida.cn/article/jgeggo.html