高性能MYSQL（学习笔记）-查询性能优化篇1

查询性能优化

为什么查询会慢

查询是一个任务，它由一系列的子任务组成，每个子任务都会消耗一定的时间。如果要优化查询，实际上要优化其子任务，要么消除其中一些子任务，要么减少子任务的执行次数，缩短响应时间。其中的任务有：客户端-服务器-生成执行计划-执行-返回，其中最主要的是执行，包括了大量为了检索数据到存储引擎的调用以及调用后的数据处理，包括排序、分组等。

在完成这些任务的时候，查询需要花费的时间，包括网络、CPU计算、生成统计信息、执行计划、锁（互斥等待）等操作。尤其是向底层引擎检索数据的调用操作，这些调用需要在内存操作、CPU操作、和内存不足时导致的I/O操作上消耗时间。

慢查询基础：优化数据访问

查询性能低下最基本的原因是访问的数据太多，分析查询性能如下步骤：

1、  确认应用程序是否在检索大量超过需要数据，这通常以为访问了太多的行，有可能是太多的列。

2、  确认mysql 服务层是否在分析大量超过需要的数据行。

是否向数据库请求了不需要的数据

有时候查询会请求超过实际的数据，这些造成的后果有，MySQL服务器带来额外的负担、增加网络开销、消耗应用服务器的CPU和内存资源。

查询不需要的列

当使用select * 时候都需要用怀疑的眼光审视，是不是真的需要返回全部的列，取出全部的列，会让优化器无法完成索引覆盖扫描这类优化，还会为服务带来额外的I/O、内存和CPU的消耗。

重复查询相同的数据

不断重复执行相同的查询，然后每次都返回相同的数据，可以先将查询的数据缓存起来，需要的时候从缓存中取出。需要的时候再从缓存中取出，这样性能会更好。

MySQL是否在扫描额外的记录

在确定查询返回需要的数据后，接下来应该看看查询为了返回结果是否扫描了过多的数据，对于MySQL，最简单的衡量查询开销的三个指标如下：

1、  响应时间

2、  扫描的行数

3、  返回的行数

没有哪个指标能够完美的平衡查询的开销，但是大致反映了查询需要访问多少数据，推算出查询运行的时间。检查慢日志是找出扫描行过多的方法。。

响应时间

响应时间包括服务时间和排队时间，服务时间是指数据库处理这个查询真正花了多长时间。排队时间是服务器因为等待某些资源而没有真正执行查询的时间，可能是等I/O操作完成，也可能是等待锁。

扫描的行数和返回的行数             

理想情况下，扫描的行数和返回的行数应该相同的，但是实际却难以达到，例如像关联查询时，服务器必须要扫描多行才能生成结果集中的一行。

扫描的行数和访问类型

在EXPLAIN语句中的TYPE列反应了访问类型，访问类型有很多种，从全表扫描到索引扫描、范围扫描、唯一索引查询、常数引用等等。速度是从慢到快，扫描的行数也是从大到小。如果查询没有办法找到合适的访问类型，那么解决的最好办法就是增加一个合适的索引。索引让MySQL以最高效、扫描行最少的方式找到需要的记录。一般的MySQL可以从三种方式应用WHERE条件，从好到坏依次为：

在索引中使用where 条件来过滤不匹配的记录，这是存储引擎层完成的。

使用索引覆盖查询（在Extra列中出现了Using inex 来返回记录）来返回记录，直接从索引中过滤不需要的记录并返回命中的结果。

从数据表中返回数据，然后过滤不满足条件的记录（在Extra 列中出现Using Where）。这在MySQL服务层完成，无须再回表查询记录。

如果发现查询需要扫描大量的数据但是只返回少数的行，那么通常可以尝试下面的技巧优化它：

1、  使用索引覆盖扫描，把所有需要用的列都放到索引中，这样存储引擎无需回表获取对应的行就可以返回了。

2、  改变库表结构。例如使用单独的汇总表

3、  重写这个复杂的查询，让MySQL优化器能够以更优化的方式执行这个查询。