前言

在实际数据库项目开发中，由于我们不知道实际查询时数据库里发生了什么，也不知道数据库是如何扫描表、如何使用索引的，因此，我们能感知到的就只有SQL语句的执行时间。尤其在数据规模比较大的场景下，如何写查询、优化查询、如何使用索引就显得很重要了。

那么，问题来了，在查询前有没有可能估计下查询要扫描多少行、使用哪些索引呢？

答案是肯定的。以MySQL为例，MySQL通过explain命令输出执行计划，对要执行的查询进行分析。

什么是执行计划呢？

简单来说，就是SQL在数据库中执行时的表现情况，通常用于SQL性能分析、优化等场景。

本文从MySQL的逻辑结构讲解，过渡到MySQL的查询过程，然后给出执行计划的例子并重点介绍执行计划的输出参数。

MySQL逻辑架构

MySQL逻辑架构分为三层，如下图。
MySQL architecture

客户端
- 如，连接处理、授权认证、安全等功能
核心服务
- MySQL大多数核心服务均在这一层
- 包括查询解析、分析、优化、缓存、内置函数（如，时间、数学、加密等）
- 所有的跨存储引擎的功能也在这一层，如，存储过程、触发器、视图等
存储引擎
- 负责MySQL中的数据存储和读取
- 中间的服务层通过API与存储引擎通信，这些API屏蔽了不同存储引擎间的差异

重点解释下查询缓存：对于select语句，在解析查询之前，服务器会先检查查询缓存（Query Cache）。如果命中，服务器便不再执行查询解析、优化和执行的过程，而是直接返回缓存中的结果集。

MySQL查询过程

如果能搞清楚MySQL是如何优化和执行查询的，对优化查询一定会有帮助。很多查询优化实际上就是遵循一些原则让优化器能够按期望的合理的方式运行。

下图是MySQL执行一个查询的过程。实际上每一步都比想象中的复杂，尤其优化器，更复杂也更难理解。本文只给予简单的介绍。
MySQL query

MySQL查询过程如下：

客户端将查询发送到MySQL服务器
服务器先检查查询缓存，如果命中，立即返回缓存中的结果；否则进入下一阶段
服务器对SQL进行解析、预处理，再由优化器生成对象的执行计划
MySQL根据优化器生成的执行计划，调用存储引擎API来执行查询
服务器将结果返回给客户端，同时缓存查询结果

执行计划

优化与执行

MySQL会解析查询，并创建内部数据结构（解析树），并对其进行各种优化，包括重写查询、决定表的读取顺序、选择合适的索引等。

用户可通过关键字提示（hint）优化器，从而影响优化器的决策过程。也可以通过通过优化器解释（explain）优化过程的各个因素，使用户知道数据库是如何进行优化决策的，并提供一个参考基准，便于用户重构查询和数据库表的schema、修改数据库配置等，使查询尽可能高效。

例子

看个例子。

mysql> explain select name, nickname, ctime from dt_user where city = 'shanghai' order by name;
+----+-------------+------------+-------+--------------------------+---------------+---------+--------+---------+-----------------------+
| id | select_type | table      | type  | possible_keys            | key           | key_len | ref    | rows    | Extra                 |
+----+-------------+------------+-------+--------------------------+---------------+---------+--------+---------+-----------------------+
|  1 | SIMPLE      | dt_user    | range | PRIMARY,idx_city_name    | idx_city_name | 2945    | NULL   | 55183   | Using index condition |
+----+-------------+------------+-------+--------------------------+---------------+---------+--------+---------+-----------------------+
1 row in set (0.00 sec)

这个执行计划给出的信息是，该查询通过一个简单的给定范围的扫描，共扫描55183行，使用index condition条件在dt_user表中筛选出，扫描过程中使用PRIMARY和idx_city_name索引。

输出参数

输出各字段解释如下。更详细的信息请参考https://dev.mysql.com/doc/refman/5.7/en/explain-output.html

id
select 查询序列号
id相同，执行顺序由上至下；id不同，id值越大优先级越高，越先被执行
select_type
查询数据的操作类型，有如下
- simple
  简单查询，不包含子查询或union
- primary
  包含复杂的子查询，最外层查询标记为该值
- subquery
  在select或where里包含子查询，被标记为该值
- derived
  在from列表中包含的子查询被标记为该值，MySQL会递归执行这些子查询，把结果放在临时表
- union
  若第二个select出现在union之后，则被标记为该值
  若union包含在from的子查询中，外层select被标记为derived
- union result
  从union表获取结果的select
table
显示该行数据是关于哪张表
partitions
匹配的分区
type
表的连接类型，其值、性能由高到底排列如下
- system
  表只有一行记录，相当于系统表
- const
  通过索引一次就找到，只匹配一行数据
- eq_ref
  唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配
  常用于主键或唯一索引扫描
- ref
  非唯一性索引扫描，返回匹配某个单独值的所有行
  用于=、< 或 > 操作符带索引的列
- range
  只检索给定范围的行，使用一个索引来选择行
  一般使用between、>、<
- index
  只遍历索引树
- ALL
  全表扫描，性能最差
前5种情况都是理想的索引的情况。通常优化至少到range级别，最好能优化到ref。
possible_keys
指出 MySQL 使用哪个索引在该表找到行记录。如果该值为 NULL，说明没有使用索引，可以建立索引提高性能
key
显示 MySQL 实际使用的索引。如果为 NULL，则没有使用索引查询
key_len
表示索引中使用的字节数，通过该列计算查询中使用的索引的长度。在不损失精确性的情况下，长度越短越好显示的是索引字段的最大长度，并非实际使用长度
ref
显示该表的索引字段关联了哪张表的哪个字段
rows
根据表统计信息及选用情况，大致估算出找到所需的记录或所需读取的行数，数值越小越好
filtered
返回结果的行数占读取行数的百分比，值越大越好
extra
包含不适合在其他列中显示但十分重要的额外信息。常见的值如下
- using filesort
  MySQL会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取
  若出现有该值，应该优化SQL语句
- using temporary
  使用临时表保存中间结果，比如，MySQL在对查询结果排序时使用临时表
  常见于order by和group by
  若出现有该值，应该优化SQL语句
- using index
  表示select操作使用了覆盖索引，避免了访问表的数据行，效率不错
- using where
  where 子句用于限制哪一行
- using join buffer
  使用连接缓存
- distinct
  发现第一个匹配后，停止为当前的行组合搜索更多的行

小结

数据库性能优化很多，本文只简单了介绍MySQL逻辑结构、查询过程和执行计划参数。根据执行计划输出的索引使用情况、扫描的行数可以预估查询效率，帮助我们重构查询、优化表结构或者索引，从而尽可能提供查询效率。

MySQL执行计划参数解析

前言

MySQL逻辑架构

MySQL查询过程

执行计划

优化与执行

例子

输出参数

小结

Reference

猜你喜欢