mysql查询优化理解涛子帅哥|面朝大海-春暖花开 ZZT

优化方法

该优化查询方法是在800W数据查询优化得出的总结
版本：mysql5.6，系统：cetnos7.1

普通优化

1、创建索引（根据业务关系，复合索引）
2、表分区（水平分区：根据查询的列来通过range水平分区，垂直分表：根据经常查询的条件新建一表（这个要结合索引来），不需要查询的条件再建一表，left join即可）
3、读写分离，读myisam，写innodB
4、php+Sphinx建立高效搜索

深入优化

1、对于索引优化这里，如果查询的时候出现limit：
原文链接
1. 直接用limit start, count分页语句，也是我程序中用的方法：

select * from product limit start, count
当起始页较小时，查询没有性能问题，我们分别看下从10， 100， 1000， 10000开始分页的执行时间（每页取20条），如下：

select * from product limit 10, 20 0.016秒
select * from product limit 100, 20 0.016秒
select * from product limit 1000, 20 0.047秒
select * from product limit 10000, 20 0.094秒

我们已经看出随着起始记录的增加，时间也随着增大，这说明分页语句limit跟起始页码是有很大关系的，那么我们把起始记录改为40w看下（也就是记录的一般左右）

select * from product limit 400000, 20 3.229秒

再看我们取最后一页记录的时间
select * from product limit 866613, 20 37.44秒
（但是在这里我用了同样的查询方法优化，我发现在没有添加索引的情况下直接查询比用了索引的查询速度回更加的快，我分析是因为添加了索引之后，不仅进行了索引查询还进行了全表扫面或者表的大部分数据的扫描，然后每条数据通过索引查询出来的记录地址去寻址）
像这种分页最大的页码页显然这种时间是无法忍受的。

从中我们也能总结出两件事情：
1）limit语句的查询时间与起始记录的位置成正比
2）mysql的limit语句是很方便，但是对记录很多的表并不适合直接使用。

对limit分页问题的性能优化方法

利用表的覆盖索引来加速分页查询
我们都知道，利用了索引查询的语句中如果只包含了那个索引列（覆盖索引），那么这种情况会查询很快。

因为利用索引查找有优化算法，且数据就在查询索引上面，不用再去找相关的数据地址了，这样节省了很多时间。另外Mysql中也有相关的索引缓存，在并发高的时候利用缓存就效果更好了。

在我们的例子中，我们知道id字段是主键，自然就包含了默认的主键索引。现在让我们看看利用覆盖索引的查询效果如何：

这次我们之间查询最后一页的数据（利用覆盖索引，只包含id列），如下：
select id from product limit 866613, 20 0.2秒
相对于查询了所有列的37.44秒，提升了大概100多倍的速度

那么如果我们也要查询所有列，有两种方法，一种是id>=的形式，另一种就是利用join，看下实际情况：

SELECT * FROM product WHERE ID > =(select id from product limit 866613, 1) limit 20
查询时间为0.2秒！

另一种写法
SELECT * FROM product a JOIN (select id from product limit 866613, 20) b ON a.ID = b.id
查询时间也很短！

还有一种写法是不通过分页序号查询页面，而是通过下面这种方式

使用"上一页"和"下一页"进行分页:
上一页(id:60~41)
当前页(id:40~21)
下一页(id:20~01)

上一页(新文章20篇):
//page.php?id=40 正数表示上一页新文章,这里的40表示当前页最上面的文章的ID.
SELECT * FROM posts WHERE id > 40 ORDER BY id ASC LIMIT 20;
这里得到的是升序ID序列,PHP使用array_reverse反转数组实现降序输出即可.

下一页(旧文章20篇):
//page.php?id=-21 负数表示下一页旧文章,这里的21表示当前页最下面的文章的ID.
SELECT * FROM posts WHERE id < 21 ORDER BY id DESC LIMIT 20;
觉得负数不好看的话,可以额外加一个参数,比如 page.php?id=21&next

explain分析

使用explain分析索引
在不确定应该在哪些数据列上创建索引的时候，我们可以从EXPLAIN SELECT命令那里往往可以获得一些帮助。这其实只是简单地给一条普通的SELECT命令加一个EXPLAIN关键字作为前缀而已。有了这个关键字，MySQL将不是去执行那条SELECT命令，而是去对它进行分析。MySQL将以表格的形式把查询的执行过程和用到的索引(如果有的话)等信息列出来。这里我基本阐述下每个信息字段含义，不展开阐述，我们只要注意几个关键点（关键点以下用红色加粗显示）能大概看懂即可呵呵
~~1、id:SQL执行的顺序的标识。~~

sql从里向外执行，通过以上观察发现sql是按照id从大到小执行的。
2、select_type: select类型
1)、SIMPLE(不使用UNION或子查询等)

2) 、PRIMARY：最外层的select

3）、DERIVED：派生表的SELECT(FROM子句的子查询)

4）、UNION：UNION中的第二个或后面的SELECT语句

5）、UNION RESULT：UNION的结果。

6）、DEPENDENT UNION：UNION中的第二个或后面的SELECT语句，取决于外面的查询

7）、SUBQUERY：子查询中的第一个SELECT

8）、DEPENDENT SUBQUERY：子查询中的第一个SELECT，取决于外面的查询

3、table：表的名字。
有时不是真实的表名字,看到的是derivedx(x是个数字,我的理解是第几步执行的结果)
4、type：连接操作的类型。
这列很重要,显示了连接使用了哪种类别,有无使用索引。在各种类型的关联关系当中，效率最高的是system，然后依次是const、eq_ref、ref、range、index和 All。一般来说，得保证查询至少达到range级别，最好能达到ref，否则就可能会出现性能问题。
1）、system
表只有一行：system表。这是const连接类型的特殊情况
2）、const
表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待
3）、eq_ref
在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用
4）、ref
这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少（越少越好）
5）、range
这个连接类型使用索引返回一个范围中的行，比如使用>或<查找东西时发生的情况
6）、index
这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据）
7）、ALL
这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免。因为它要扫描整个表。你可以加入更多的索引来解决这个问题。
5、possible_key：MySQL在搜索数据记录时可以选用的各个索引名。
这里的索引名是创建索引时指定的索引昵称;如果索引没有昵称，则默认显示的是索引中第一个列的名字(在上一节举的例子中是“firstname”)。默认索引名字的含义往往不是很明显。
6、key：它显示了MySQL实际使用的索引。
key数据列是MySQL实际选用的索引，如果它为空(或NULL)，则MySQL不使用索引。
7、key_len：索引中被使用部分的长度，以字节计。
key_len的值可以告诉你在联合索引中mysql会真正使用了哪些索引。在上例中，key_len是102，其中firstname占50字节，lastname占50字节，age占2字节（smallint存储大小为2字节）。如果MySQL只使用索引中的firstname部分，则key_len将是50。 在不损失精确性的情况下，key_len数据列里的值越小越好(意思是更快)。
8、ref：显示使用哪个列或常数与key一起从表中选择行。
ref数据列给出了关联关系中另一个数据表里的数据列的名字。
9、rows：MySQL所认为的它在找到正确的结果之前必须扫描的记录数。
显然，这里最理想的数字就是1。
10、extra：附加信息
Using index和Using where会遇到的比较多，可以重点记下，其他的我没怎么遇到过了解即可，遇到具体问题可以查阅哈
1）、Distinct
一旦MYSQL找到了与行相联合匹配的行，就不再搜索了
2）、Not exists
MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了
3）、Range checked for each
没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一
4）、Using filesort
看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行 **
5）Using index
列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候
6）Using temporary
**看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上
7）Using where
使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题