学习MySQL怎样优化查询速度

前面章节我们介绍了怎样选中优化的数据类型、怎样高效的使用索引，这些关于高机能的MySQL来说是必不成少的。 但这些还完全不足，还需要合理的设计查询。 假如查询写的很糟糕，即便表构造再合理、索引再适宜，也是没法实现高机能的。

谈到MySQL机能优化，查询优化作为优化的泉源，它也是最能表现一个系统可否更快。 本章乃至接下来的几章将会着重讲解关于查询机能优化的内容，从中会介绍一些查询优化的技巧，帮忙大家更深刻地懂得MySQL怎样真正地施行查询、毕竟慢在哪里、怎样让其快起来，并清楚高效和低效的缘由安在，这样更有助于你更好的来优化查询SQL语句。

相关学习引荐：mysql视频教程

本章从“为什么查询速度这么慢”开端谈起，让你能够分明的知道查询大概会慢在哪些环节，这样将有助于你更好的优化查询，做到 成竹在胸，高人一筹 。

一、慢在哪

真正衡量查询速度的是响应时间。 假如把查询看作是一个任务，那么它是由一系列子任务组成的，每个任务都会耗损必然的时间。 假如要优化查询，实际上要优化其子任务，那么消弭其中一些子任务，那么减少子任务的施行次数，要末让子任务运转的更快。

MySQL在施行查询的时候，是什么子任务，哪些子任务花费的时间最多？ 这就需要借助一些工具，或者一些办法(如： 施行方案)对查询停止分析，来定位发明毕竟慢在哪。

平常来说，查询的生命周期大致大致可以依照次序来看： 从客户端到效劳器，然后在效劳器上停止解析，生成施行方案，施行，并返回结果给客户端。 其中，“施行”可以认为是整个生命周期中最重要的阶段，这其中包罗了大量为了检索数据到储备引擎的调取乃至调取后的数据处置，包罗排序、分组等。

在完成这些任务的时候，查询需要在不一样阶段的不一样地方花费时间，包罗网络、CPU运算，生成统计信息和施行方案、锁等候等操纵，特别是向底层储备引擎检索数据的调取操纵，这些调取需要在内存操纵、CPU操纵，还大概会发生大量的上下文切换乃至系统调取。

在上述这些操纵中，都会耗损大量的时间，其中会存在一些不必要的额外操纵，其中有些操纵大概被额外地反复施行了许多次、某些操纵施行的很慢等等。 这也就是查询真正大概慢的地方， 优化查询的目的就是减少和消弭这些操纵所花费的时间 。

通过上面的剖析，我们对查询的历程有了团体的理解，能够分明的知道查询大概在哪些地方会存在问题，终究致使整个查询很慢，为实际查询优化供给标的目的。

换言之，查询优化可以从以下两个角度来动身：

• 减少子查询次数
• 减少额外、反复的操纵

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

• 可否查询了不需要的数据
• 可否扫描了额外的记载

二、可否查询了不需要的数据

在实际查询中许多时候，会查询了实际需要的数据，然后这些余外的数据会被利用程序抛弃。 这对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，那么会员屡次评论的时候，大概就会重复来查询这个数据。 比力好处置办法是，在初次查询的时候将这个数据缓存起来，后续使用时直接从缓存中取出。

三、可否扫描了额外的记载

确 定查询只查询了需要的数据今后，接下来应当看看查询历程中可否扫描了过多的数据。 关于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优化器能够以更优化的方式施行这个查询。

相关引荐：编程视频课程

以上就是学习MySQL怎样优化查询速度的具体内容，更多请关注百分百源码网其它相关文章！