文章目录
MySQL是否在扫描额外的记录
- 在确定查询只返回需要的数据之后，接下看看看查询是否为了返回结果扫描了过多的数据。三个衡量查询开销的指标如下：
- 响应时间
- 扫描的行数
- 返回的行数
- 这三个指标都会记录到MySQL的慢日志中，所以检查慢日志记录是找出扫描过多行数的查询的好办法。
响应时间
- 响应时间只是一个表面上的值。
- 响应时间是两部分之和：服务时间和排队时间。服务时间是指数据库处理这个查询真正花了多长时间。排队时间是指服务器因为等待某些资源而没有真正执行查询的时间-可能是等待I/O操作完成，也可能是等待行锁等待。所以在不同类型压力下，响应时间并没有什么一致的规律和公式。诸如存储引擎的锁（表锁、行锁）、高并发资源竞争、硬件响应等诸多因素都会影响响应时间。
- 当看到一个响应时间的时候，首先要问问自己这是不是一个合理的值。实际上可以使用“快速上限估计”来估算查询的响应时间。概况的说，了解这个查询需要那些索引以及它的执行计划是什么，然后大概需要多少个顺序和随机IO，再用其乘以具体硬件条件的一次IO的消耗时间。最后把这些消耗加起来，就可以获得一个大概参考值来判断当前响应时间是不是一个合理的值。
扫描的行数的返回的行数
- 分析查询是，查看该查询扫描的行数是非常有帮助的。
- 并不是所有的行的访问代价是相同的。较短的行的访问速度更快，内存中的行也比磁盘中的行的访问速度快的多。
- 理想情况下，扫描的行数和返回的行数应该是相同的。但实际情况下，这种“美事”并不多。例如，关联查询时，服务器必须扫描多行才能生成一行。扫描的行数对返回的行数的比率通常很小，一般在1:1和10:1之间，不过有时候这个值也可能非常非常大。
扫描的行数和访问类型
- 在评估查询开销的时候，需要考虑一下从表中找到某一行的成本。MySQL有好几种方式可以查找并返回一行结果。有些访问方式需要扫描很多行才能返回一行结果，有些可能无需扫描就能返回结果。
- 在EXPLAIN的type类反应了访问类型。访问类型包含全表扫描、索引扫描 、范围扫描、唯一索引查询、常识引用。它们的速度从慢到快。
- 索引能让MySQL以最高效、扫描行数最少的方式找到需要的记录。
- 一般MySQL使用如下三种方式引用WHERE条件，从好到坏依次为：
- 在索引中使用WHERE条件来过滤不匹配的记录。这是在存储引擎层完成的。
- 使用索引覆盖扫描（在Extra列中出现了Using index）来返回记录 ，直接从索引中过滤不需要的记录并返回命中的结构。在MySQL服务器层完成的。无需回表。
- 从数据表中返回数据，然后过滤不需要的数据（在Extra列中出现Using where）。在MySQL服务器层完成，需要先读出数据在过滤。
- 好的索引可以让查询使用合适的访问类型，尽可能的只扫描需要的数据行。但也不是说增加索引就能让扫描的行数等于返回的行数。
- 如果发现查询需要扫描大量的数据但只返回少数的行，那么通常可以尝试下面的技巧去优化它：
- 使用索引覆盖扫描，把需要用到的列都放到索引中，这样存储引擎就无需回表就可以返回结果了。
- 改变库结构。例如使用单独的汇总表。
- 重新这个复杂的查询。让MySQL能以更优化的方式执行这个查询。
重构查询的方式
一个复杂查询还是多个简单查询
- 设计查询的时候一个需要考虑的重要的问题是，是否需要将一个复杂的查询分成多个简单的查询。
- 在传统的实现中，总是强调需要数据库层完成尽可能多的工作，这样做的逻辑在于以前总是认为网络通信、查询解析和优化是一键代价很高的事情。
- 但是这样的想法对MySQL并不适用，MySQL从设计上让连接和断开连接都很轻量级。在返回一个小的查询结果方面很高效。所以运行多个小查询现在已经不是大问题了。
- MySQL内部每秒能够扫描内存中上百万行数据，相比之下，MySQL响应数据给客户端就慢得多了。在其他条件都相同的时候，使用尽可能少的查询当然是更好的。但是有时候，将一个大查询分解为多个小查询是很有必要的。别害怕这样做，好好衡量一下这样做是不是会减少工作量。
切分查询
- 有时候需要对一个大查询“分而治之”，将大查询切分为多个小查询，小查询的功能完全一样，每次只完成一小部分，只返回一小部分查询结果。
- 删除旧数据就是一个很好的例子。定期清理大量数据时，如果用一个大语句一次性完成的话，可能需要一次锁住很多数据，占满整个事务日志，耗尽系统资源，阻塞很多小但重要的查询。我们可以分多次删除。
- 一次性删除一万行数据一般来说是一个比较高效而且对服务器影响也最小的做法（如果是事务型引擎，很多时候小事务能够更高效）。同时需要注意的是，每次删除后，都暂停一会儿再做下一次删除，这样可以将服务器原本一次性的眼里分散到一个很长的时间段中，就可以大大降低对服务器的影响，还可以大大减少删除时锁的持有时间。
分解关联查询
- 很多高性能的应用都会对关联查询进行分解。简单地，可以对每一个表进行一次单表查询，然后将结果在应用程序中进行关联。
- 用分解关联查询重构查询的优势如下：
- 让缓存的效率更高。很多应用程序可以方便的缓存单表对应的结果对象。另外，对于MySQL的查询缓存来说，如果关联中的某个表发生了变化，查询缓存就无效了。而拆分后，如果某个表很少改变，就可以重复利用查询缓存结果了。
- 将查询分解后，执行单个查询可以检索锁的竞争。
- 在应用层做拆分，可以更容易对数据库进行拆分，更容易做到高性能和高扩展。
- 查询本身的效率也有可能提升。使用IN()代替关联查询，可以让MySQL安装ID顺序进行查询，这可能比随机的关联要更高效。
- 可以减少冗余记录的查询。在应用层做关联查询，意味着某个记录应用只需要查询一次，而在数据库中做关联查询，则可能需要重复地访问一部分数据。从这点看，这样的重构还可能会减少网络和内存的消耗。
- 更进一步，这样做相当于在应用中实现了哈希关联，而不是使用MySQL的嵌套循环关联。某些场景哈希关联的效率要高很多。
- 在很多场景下，将关联放到应用程序中将会更加高效，比如：当应用能够很方便的缓存单个查询的时候、当可以将数据分布到不同的MySQL服务器上的时候，当能够使用IN()代替关联查询的时候、当查询中使用同一个数据表的时候。
查询执行的基础
- 当希望MySQL能够以更高的性能运行查询时，最好的办法是弄清除MySQL是如何优化和执行查询的。一旦理解这一点，很多查询优化工作实际上就是遵循一些原则让优化器能够按照预想的合理的方式运行。
- MySQL的执行过程如下：
- 客户端发送一个查询给服务器。
- 服务器先检查查询缓存，如果命中了缓存，则直接返回缓存中的结构。否则进入下一个阶段。
- 服务器端进行SQL解析、预处理，再有优化器生成对应的执行计划。
- MySQL根据优化器生成的执行计划，调用存储引擎的API来执行查询。
- 将结果返回给客户端。
MySQL客户端和服务器通信协议
- MySQL客户端和服务器的通信协议是“半双工”的，这意味着，在任何一个时刻，要么是有服务器向客户端发送数据，要么是由客户端向服务器发送数据，这两个动作无法同时发生。所以，我们无法也无须将一个消息切成小块独立来发送。
- 这种协议让MySQL通信简单快速，但是也从很多地方限制了MySQL。一个明显的限制是，无法进行流量控制。一旦一端开始发送消息，另一端要接受完整个消息才能响应它。
- 客户端用一个单独的数据包将查询传给服务器。一旦客户端发送了请求，它能做的事情就只能是等待结果了。当查询语句很长的时候，参数max_allowed_packet特别重要（如果查询太多，服务器会拒绝接受更多的数据并抛出相应的错误）。
- 服务器发送给客户端的数据通常很多，由多个数据包组成。当服务器开始相应客户端的时候，客户端必须完整地接受整个返回结果，而不是简单的取前面几条数据，让服务器停止发送数据。这种情况下，客户端若接收完整的结果，然后取前面几条需要的结果，或者接收完几条结果后就“粗暴”地断开连接，都不是好主意。这也是在必要的时候一定要在查询中加上LIMIT 限制的原因。
- 换一种方式解释这种行为：当客户端从服务器取数据时，看起来是一个拉数据的过程，但实际上是MySQL在向客户端推送数据的过程。客户端不断地接收从服务器推送的数据，客户端也没法让服务器停下来。客户端像是“从消防水管喝水”。
- 多数连接MySQL的库函数都可以获得全部结果集并缓存到内存里，还可以逐行获取需要的数据。默认一般是获得全部结果集并缓存到内存中。MySQL通常需要等所有的数据都已经发送给客户端才能释放这条查询所占用的资源，所以接收全部结果并缓存通常可以减少服务器的压力，让查询能够早点结束、早点释放相应的资源。
- 当使用多数连接MySQL的库函数从MySQL获取数据时，其结果看起来都像是从MySQL服务器获取数据，而实际上都是从这个库函数的缓存获取数据。多数情况下这没什么问题，但是如果需要返回一个很大的结果集的时候，这样做并不好，因为库函数会花很多时间和内存来存储所有的结果集。如果能够尽早开始处理这些结果集，就能大大减少内存的消耗，这种情况下可以不使用缓存来记录结果而是直接处理。这样做的缺点是，对于服务器来说，需要查询完成后才能释放资源，所以在和客户端交互的整个过程中，服务器的资源都是被这个查询所占用的。
查询状态
对应一个MySQL连接，或者说一个线程，任何时刻都有一个状态，表示MySQL当前正在做什么。有很多方式可以查看MySQL当前的状态，如SHOW FULL PROCESSLIST（该命令返回的Command列就表示当前的状态）。在一个查询的生命周期中，状态会变化多次。
- Sleep
线程正在等待客户端发送新的请求。 - Query
线程正在执行查询或者正在将结果发送给客户端。
Locked
在MySQL服务器层，该线程正在等待表锁。在存储引擎级别实现的锁，例如InnoDB的行锁，并不会体现在线程状态中。对于MyISAM来说这是一个比较典型的状态，但在其他没有行锁的引擎中也经常会出现。 - Analyzing and statistics
线程正在收集存储引擎的统计信息，并生成查询的执行计划。 - Copying to tmp table [on disk]
线程正在执行查询，并且将其结果集都复制到一个临时表中，这种状态一般要么是在做GROUP BY 操作，要么是文件排序操作，或者是UNION操作。如果这个状态后面还有“on disk”标记，那表示MySQL正在将一个内存临时表放到磁盘上。 - The thread is
线程正在对结果集进行排序。 - Sending data
这表示多种情况：线程可能在多个状态之间传送数据，或者在生成结果集，或者在向客户端返回数据。
查询缓存
- 在解析一个查询语句前，如果查询缓存是开启的，那么MySQL会优先检查这个查询是否命中查询缓存中的数据。这个检查是通过一个对大小写敏感的哈希查找来实现的。查询和缓存中的查询即使只有一个字节不同，那也不会匹配缓存结果。
- 如果查询恰好命中了缓存，那么在返回查询之前会检查一次用户权限。这仍然是无须解析查询SQL语句的，因为在查询缓存中已经存放了当前查询需要访问的表信息。如果权限没有问题，MySQL会跳过所有其他阶段，直接从缓存中拿到结果并返回给客户端。这种情况下，查询不会被解析，不用生成执行计划，不会被执行。
查询的优化处理
查询的生命周期的下一步是将一个SQL转换成一个执行计划，MySQL再依照这个执行计划和存储引擎进行交互。这包括多个子阶段：解析SQL、预处理、优化SQL执行计划。这个过程中任何错误（例如语法错误）都可能终止查询。
语法执行器和预处理
- 首先，MySQL通过关键字将SQL语句进行解析，并生成一颗对应“解析树”。MySQL解析器将使用MySQL语法规则验证和解析查询。例如，它将验证是否使用错误的关键字，或者使用关键字的顺序是否正确等，再或者它还会验证引号是否能前后正确匹配。
- 预处理器则根据一些MySQL规则进一步检查解析树是否合法，例如，这里将检查数据表和数据列是否存在，还会解析名字和别名，看看它们是否有歧义。
- 下一步预处理器会验证权限。这通常很快，除非服务器上有非常多的权限配置。
查询优化器
- 如果语法树被认为是合法了，并且有优化器将其转化为执行计划。一条查询可以有很多中执行方式，最后都返回相同的结果。优化器的作用就是找到这其中最好的执行计划。
- MySQL使用基于成本的优化器，它将尝试预测一个查询使用某种执行计划时的成本，并选择最小的一个。
- 可以通过查询当前会话的
Last_query_cost的值来计算当前查询的成本。
mysql> SELECT SQL_NO_CACHE COUNT(*) FROM film_actor;
mysql> SHOW STATUS LIKE ‘Last_query_cost’;
它的值会返回1040.599000。这个结果表明MySQL的优化器任务大概需要做1040个数据页的随机查找才能完成上面的查询。 这是根据一系列的统计信息计算得来的：每个表或者索引的页面个数、索引的基数（索引中不同值的数量）、索引和数据行的长度、索引分布情况。优化器在评估成本的时候并不考虑任何层面的缓存，它假设读取任何数据都需要一次磁盘I/O。
- 有很多原因会导致MySQL优化器选择错误的执行计划。如下所示：
- 统计信息不准确。MySQL依赖存储引擎提过的统计信息来评估成本，但有的存储引擎提供的信息是准确的，有的偏差可能非常大。例如，InnoDB因为其MVCC的架构，并不能维护一个数据表的行数的精确统计信息。
- 执行计划中的成本估算并不等同于实际执行的成本。所以即使统计信息精准，优化器给出的执行计划也可能不是最优的。例如有时候某个执行计划虽然需要读取更多的页面，但是它的成本却更小。因为如果这些页面都是顺序读或者这些页面都已经在内存中的话，那么它的访问成本将很小。MySQL层面并不知道哪些页面在内存中、哪些在磁盘上，所以查询实际执行过程中到底需要多少次物理I/O是无法得知的。
- MySQL的最优可能和你想的最优不一样。你可能希望执行时间尽可能的短，但是 MySQL只是基于其成本模型选择最优的执行计划，而有些时候这并不是最快的执行方式。所以，这里我们看到根据执行成本来选择执行计划并不是完美的模型。
- MySQL从不考虑其他并发执行的查询，这可能会影响到当前查询的速度。
- MySQL也并不是任何时候都是基于成本的优化。有时也会基于一些固定的规则，例如，如果存在全文搜索的MATCH()子句，则在存在全文索引的时候就使用全文索引。即使有时候使用别的索引和WHERE 条件可以远比这种方式要快，MySQL也仍然会使用对应的全文索引。
- MySQL不会考虑不受其控制的操作的成本，例如执行存储过程或者用户自定义函数的成本。
- 优化器有时候无法去估算所有可能的执行计划，所以它可能错过实际上最优的执行计划。
- MySQL的查询优化器是一个非常复杂的部件，它使用了很多优化策略来生成一个最优的执行计划。优化策略可以简单分为两种：静态优化和动态优化。
- 静态优化可以直接对解析树进行分析，并完成优化。例如，优化器可以通过一些简单的代数变换将WHERE 条件转换成另一种等价形式。静态优化不依赖于特别的数值，如WHERE 条件中带入的一些常数等。静态优化在第一次完成后就一直有效，即使使用不同的参数重复执行查询也不会发生变化。可以认为这是一种“编译时优化”。
- 动态优化则和查询的上下文有关。也可能和很多其他因素有关，例如WHERE 条件中的取值、索引中条目对应的数据行数等。这需要在每次查询的时候都重新评估，可以认为这是“运行时优化”。
- 在执行语句和存储过程的时候，动态优化和静态优化的区别非常重要。MySQL对查询的静态优化只需要做一次，但对查询的动态优化则在每次查询执行时都需要重新评估。有时候甚至在查询的执行过程中也会重新优化。例如，在关联操作中，范围检查的执行计划会针对每一行重新评估索引。可以通过EXPLAIN执行计划中的Extra列看是否有"range checked for each record"来确认这一点。
- 下面是一下MySQL能够处理的优化类型：
- 重新定义关联表的顺序
数据表的关联并总是按照查询中指定的顺序执行。决定关联的顺序是优化器很重要的一部分功能。 - 将外连接转换为内连接
并不是所有的OUTER JOIN都必须以外连接的方式执行。诸多因素，例如WHERE条件，库表结构都可能会让外连接等价于一个内连接。MySQL能够识别这点并重新查询，让其可以调整关联顺序。 - 使用等价变化规则
MySQL能够使用一些等级变化来简化并规范表达式。它可以合并和减少一些比较，还可以移除一些恒成立和一些恒不成立的判断。例如，（5=5 AND a>5）则被改写为a>5。 - 优化COUNT()、MIN()、MAX()
索引和列是否为空通常可以帮助MySQL优化这类表达式。例如，要找到某一列的最小值，只需要查询对应B-Tree索引最左边的记录，MySQL可以直接获取索引的第一行记录。在优化器生成执行计划的时候就可以利用这一点，在B-Tree索引中，优化器会将这个表达式作为一个常数对待。如果MySQL使用了这种类型的优化，那么在EXPLAIN中就可以看到Select tables optimized away。它表示优化器已经从执行计划中移除了该表，并以一个常数取而代之。
类似的，没有任何WHERE 条件的COUNT（*） 查询通常也可以使用存储引擎提供的一些优化（例如，MyISAM维护了一个变量来存放数据表的行数）。 - 预估并转换为常数表达式
当My例如，一个用户自定义变量在查询中没有发生变化时就可以转换为一个常数。数学表达式则是另一种典型的例子。SQL检测到一个表达式可以转化为常数的时候，就会一直把该表达式作为常数进行优化处理。
让人惊讶的是，在优化阶段，有时候甚至一个查询也能够转化为一个常数。一个例子是在索引列上执行MIN() 函数。甚至是主键或者唯一键查找语句也可以转换为常数表达式。如果WHERE 子句中使用了该类索引的常数条件，MySQL可以在查询开始阶段就先查找到这些值，这样优化器就能够知道并转换为常数表达式。
另一种会看到常数条件的情况是通过等式将常数值从一个表传到另一个表，这可以通过WHERE、USING 或者ON 语句来限制某列取值为常数。 - 覆盖索引扫描
当索引中的列包含所有查询中需要使用的列的时候，MySQL就可以使用索引返回需要的数据，而无须查询对应的数据行。 - 子查询优化
MySQL在某些情况下可以将子查询转换为一种效率更高的形式，从而减少多个查询多次对数据进行访问。 - 提前终止查询
在发现已经满足查询需要的时候，MySQL总是能够立即终止查询。如，使用LIMIT的时候，发现了一个不成立的条件，这是MySQL可以立刻返回一个空结果。
除此之外，MySQL发现某些特殊的条件，则会提前终止查询。如，当存储引擎需要检索“不同值”和判断存在性的时候。
类似这种“不同值/不存在”的优化一般可用于DISTINCT 、NOT EXIST() 或者LEFT JOIN 类型的查询。