MySQL查询优化的示例分析

小编给大家分享一下MySQL查询优化的示例分析,希望大家阅读完这篇文章之后都有所收获、下面让我们一起去探讨吧!

<强>一、优化的思路和原则有哪些

1,优化更需要优化的查询
2,定位优化对象的性能瓶颈
3,明确优化的目标
4,从解释入手
5,多使用配置文件
6,永远用小结果集驱动大结果集
7,尽可能在索引中完成排序
8只取出自己需要的字段(列)
9日仅仅使用最有效的过滤条件
10,尽可能避免复杂的加入

<强>相关免费学习推荐: <强> MySQL视频教程

<强> 1,优化更需要优化的查询

?高并发的低消耗(相对)的查询对整个系统影响远大于低并发高消耗的查询。

<强> 2,定位优化对象的性能瓶颈

?在拿到一条需要优化的查询时,我们首先要判断出这个查询的瓶颈到底是IO还是CPU。到底是数据库访问消耗多还是数据的运算(如分组排序)消耗多。

<强> 3,明确优化的目标

?了解数据库目前整体状态,就能知道数据库所能承受的最大压力,也就是我们知道最悲观状况,
?要把握该查询相关的数据库对象信息,我们就能知道最理想和最糟糕状态下需要消耗多少资源;
?要知道该查询在应用系统中的地位,我们可以分析出改查询可以占用系统资源的比例,也能够知道该查询的效率对客户的体验影响有多大。

<强> 4,从解释入手

解释能够告诉你这个查询在数据库中是一个什么样的执行计划来实现的。首先我们需要有个目标,通过不断调整尝试,再借助解释来验证结果是否满足自己的需求,直到得到预期的结果。

<强> 5,永远用小结果集驱动大结果集

?很多人喜欢在SQL优化的时候说用“<强>小表驱动大表强”,这个说法是不严谨的。因为大表经过哪条件过滤后返回的结果集并不一定就比小表所返回的结果集大,这个时候还用大表驱动小表,就会得到相反的性能效果。
?这样的结果也非常容易理解,在MySQL中的加入,只有嵌套循环一种加入方式,也就是MySQL的加入都是通过嵌套循环来实现的。驱动结果集越大,所需要循环的此时就越多,那么被驱动表的访问次数自然也就越多,而每次访问被驱动表,即使需要的逻辑IO很少,循环次数多了,总量自然也不可能很小,而且每次循环都不能避免的需要消耗CPU,所以CPU运算量也会跟着增加,所以,如果我们仅仅以表的大小来作为驱动表的判断依据,假若小表过滤后所剩下的结果集比大表多很多,结果就是需要的嵌套循环中带来更多的循环次数,反之,所需要的循环次数就会更少,总体输入输出量和CPU运算量也会少,而且,就算是非嵌套循环的加入算法,如甲骨文中的散列连接,同样是小结果集驱动大的结果集是最优的选择。
?所以,在优化连接查询的时候,最基本的原则就是“小结果集驱动大结果集”,通过这个原则来减少嵌套循环中的循环次数,达到减少IO总量以及CPU运算的次数。尽可能在索引中完成排序

<强> 6,只取出自己需要的字段(列)

?对于任何查询,返回的数据都是需要通过网络数据包传输给客户端,如果取出的列越多,需要传输的数据量自然会越大,不论从网络带宽还是网络传输缓冲区来看,都是一种浪费。

<强> 7,仅仅使用最有效的过滤条件

?举个例子一个用户表用户有id和nick_name等字段,索引是id和nike_name两个索引、下面是两个查询语句