MySQL性能优化(五)：为何查询速度这么慢

前期回顾：
MySQL性能优化(一)：MySQL架构与核心问题
MySQL性能优化(二)：选择优化的数据类型
MySQL性能优化(三)：深刻理解索引的这点事
MySQL性能优化(四)：如何高效正确的使用索引

前面章节咱们介绍了如何选择优化的数据类型、如何高效的使用索引，这些对于高性能的MySQL来讲是必不可少的。但这些还彻底不够，还须要合理的设计查询。若是查询写的很糟糕，即便表结构再合理、索引再合适，也是没法实现高性能的。

谈到MySQL性能优化，查询优化做为优化的源头，它也是最能体现一个系统是否更快。本章以及接下来的几章将会着重讲解关于查询性能优化的内容，从中会介绍一些查询优化的技巧，帮助你们更深入地理解MySQL如何真正地执行查询、究竟慢在哪里、如何让其快起来，并明白高效和低效的缘由何在，这样更有助于你更好的来优化查询SQL语句。

本章从“为何查询速度这么慢”开始谈起，让你可以清楚的知道查询可能会慢在哪些环节，这样将有助于你更好的优化查询，作到心中有数，高人一筹。

1、慢在哪

真正衡量查询速度的是响应时间。 若是把查询看做是一个任务，那么它是由一系列子任务组成的，每一个任务都会消耗必定的时间。若是要优化查询，实际上要优化其子任务，那么消除其中一些子任务，那么减小子任务的执行次数，要么让子任务运行的更快。

MySQL在执行查询的时候，有哪些子任务，哪些子任务花费的时间最多？这就须要借助一些工具，或者一些方法(如：执行计划)对查询进行剖析，来定位发现究竟慢在哪。

一般来讲，查询的生命周期大体大体能够按照顺序来看：从客户端到服务器，而后在服务器上进行解析，生成执行计划，执行，并返回结果给客户端。 其中，“执行”能够认为是整个生命周期中最重要的阶段，这其中包括了大量为了检索数据到存储引擎的调用以及调用后的数据处理，包括排序、分组等。

在完成这些任务的时候，查询须要在不一样阶段的不一样地方花费时间，包括网络、CPU计算，生成统计信息和执行计划、锁等待等操做，尤为是向底层存储引擎检索数据的调用操做，这些调用须要在内存操做、CPU操做，还可能会产生大量的上下文切换以及系统调用。

在上述这些操做中，都会消耗大量的时间，其中会存在一些没必要要的额外操做，其中有些操做可能被额外地重复执行了不少次、某些操做执行的很慢等等。这也就是查询真正可能慢的地方，优化查询的目的就是减小和消除这些操做所花费的时间。

经过上面的分析，咱们对查询的过程有了总体的了解，可以清楚的知道查询可能在哪些地方会存在问题，最终致使整个查询很慢，为实际查询优化提供方向。

换言之，查询优化能够从如下两个角度来出发：

• 减小子查询次数
• 减小额外、重复的操做

查询性能低下常见的缘由是访问的数据太多。在数据量小的时候，查询速度还不错，一旦数据量上来，查询速度将会发生巨变，让人抓狂、体验极差。针对查询优化方面，能够从如下方面进行排查：

• 是否查询了不须要的数据
• 是否扫描了额外的记录

2、是否查询了不须要的数据

在实际查询中不少时候，会查询了实际须要的数据，而后这些多余的数据会被应用程序丢弃。这对MySQL来讲是额外的开销，同时也会消耗应用服务器的CPU和内存资源。

一些典型案例以下：

1. 查询不须要的记录

这是一个常见的错误，经常会误觉得MySQL只会返回须要的数据，实际上MySQL倒是先返回所有结果集再进行计算。

开发者习惯性的先使用SELECT语句查询大量的结果，而后由应用查询或者前端展现层再获取前面的N行数据，例如，在新闻网站中查询100条记录，可是只是在页面上显示前10条。

最有效的解决方法是须要多少记录就查询多少记录，一般会在查询后面加上LIMIT，即：分页查询。

2. 多表关联时返回所有列

若是你想查询全部在电影Academy Dinosaur中出现的演员，千万不要按下面的方式来进行查询：

select * fromt actor a
inner join film_actor fa.actorId = a.actorId
inner join film f f.filmId = fa.filmId
where fa.title = 'Academy Dinosaur';

这样将会返回三张表的所有数据列，而实际需求是要查询演员信息，正确的写法应该是：

select a.* fromt actor a
inner join film_actor fa.actorId = a.actorId
inner join film f f.filmId = fa.filmId
where fa.title = 'Academy Dinosaur';

3. 老是查询出所有列

每次看到select *的时候必定要用异样的目光来审视它，是否是真的须要返回所有数据列？

在大部分状况下，是不须要的。select *会致使进行全表扫描，会让优化器没法完成索引扫描这类优化，过多的列还会为服务器带来额外的I/O、内存和CPU的消耗。即便真的须要查询出所有列，应该逐个罗列出所有列而不是*。

4. 重复查询相同的数据

若是你不太留意，很容易出现这样的错误：不断地重复执行相同的查询，而后每次都返回彻底相同的数据。

例如，在用户评论的地方须要查询用户头像的URL，那么用户屡次评论的时候，可能就会反复来查询这个数据。比较好处理方法是，在初次查询的时候将这个数据缓存起来，后续使用时直接从缓存中取出。

3、是否扫描了额外的记录

肯定查询只查询了须要的数据之后，接下来应该看看查询过程当中是否扫描了过多的数据。对于MySQL，最简单衡量查询开销的三个指标以下：

• 响应时间
• 扫描的行数
• 返回的行数

没有哪一个指标可以彻底来衡量查询的开销，但它们可以大体反映MySQL内部执行查询时须要访问多少数据，并能够大概推算出查询运行的实际。这三个指标都会记录到MySQL的慢日志中，因此检查慢日志记录是找出扫描行数过多查询的办法。

慢查询：用于记录在MySQL中响应时间超过阈值(long_query_time,默认10s)的语句，并会将慢查询记录到慢日志中。可经过变量slow_query_long来开启慢查询，默认是关闭状态，能够将慢日志记录到表slow_log或文件中，以供检查分析。

1. 响应时间

响应时间是两个部分之和：服务时间和排队时间。服务时间是指数据库处理这个查询真正花费了多长时间。排队时间是指服务器由于等待某些资源而没有真正执行查询的时间，多是等待I/O操做，也多是等待行锁等等。

在不一样类型的应用压力下，响应时间并无什么一致的规律或者公式。诸如存储引擎的锁（表锁，行锁），高并发资源竞争，硬件响应等诸多因素都会影响响应时间，因此，响应时间既多是一个问题的结果也多是一个问题的缘由，不一样案例状况不一样。

当你看到一个查询的响应时间的时候，首先须要问问本身，这个响应时间是不是一个合理的值。

2. 扫描的行数和返回的行数

在分析查询时，查看该查询扫描的行数是很是有帮助的，在此之上也可以分析是否扫描了额外的记录。

对于找出那些糟糕查询，这个指标可能还不够完美，由于并非全部行的访问代价都是相同的。较短的行的访问速度至关快，内存中的行也比磁盘中的行的访问速度要快的多。

**理想的状况下，扫描的行数和返回的行数应该是相同的。**但实际上这种美事并很少，例如在作一个关联查询的时候，扫描的行数和对返回的行数的比率一般都很小，通常在1:1和10：1之间，不过有时候这个值也可能很是大。

3. 扫描的行数和访问类型

在评估查询开销的时候，须要考虑一下从表中找到某一行数据的成本。MySQL有好几种访问方式能够查找并返回一行结果。这些访问方式可能须要访问不少行才能返回一条结果，也有些访问方式可能无需扫描就能返回结果。

在执行计划EXPLAIN语句中的type列反映了访问类型。访问类型有不少种，从全表扫描到索引扫描，范围扫描，惟一索引，常数索引等。这里列的这些，速度是从慢到快，扫描的行数也是从多到少。

若是查询没有办法找到合适的访问类型，那么解决的最好办法一般就是增长一个合适的索引，这也是咱们以前讨论索引的问题。如今应该明白为何索引对于查询优化如此重要了。索引让MySQL以最高效，扫描行数最少的方式找到须要的记录。

若是发现查询扫描了大量的数据但只返回少数的行，一般能够尝试下面的技巧去优化它：

• 使用索引覆盖扫描，把全部须要用的列都放到索引中，这样存储引擎无需回表获取对应的行就能够返回结果了。
• 优化表结构。例如使用单独的汇总表来完成查询。
• 重写复杂查询，让MySQL优化器可以以更优化的方式执行这个查询。