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

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

相关免费学习推荐：mysql视频教程

1、优化更需要优化的查询

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

2、定位优化对象的性能瓶颈

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

3、明确优化的目标

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

4、从Explain入手

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

5、永远用小结果集驱动大结果集

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

6、只取出自己需要的字段（Columns）

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

7、仅仅使用最有效的过滤条件

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

#1
select * from user where id = 1 and nick_name = 'zs';
#2
selet * from user where id = 1

喜欢 (0)赏

[搞代码]

分享 (0)