01|基础架构: 一条SQL查询语句是如何执行的

本文作为学习笔记, 侵删, 原内容来自于极客时间MySQL实战45讲
01|基础架构: 一条SQL查询语句是如何执行的
02|日志系统: 一条SQL更新语句是如何执行的
03|事务隔离: 为什么你改了我还看不见
04|深入浅出索引(上)
05|深入浅出索引(下)
06|全局锁和表锁 : 给表加个字段怎么有这么多阻碍
07|行锁功过 : 怎么减少行锁对性能的影响
08|事务到底是隔离的还是不隔离的
实践篇
MySQL基本篇

基础篇(01)

有一个简单的表, 表里只有一个ID字段, 在执行下面查询语句时:

mysql> select * from T where ID=10；

输入一个语句, 返回一个结果, 但不知道这条MySQL内部的执行过程.

MySQL的基本构架图

大体可以分为Server层和存储引擎两部分.

Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等.

而存储引擎层负责数据的存储和提取. 其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎. 现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎.

在建表时, 如果不指定引擎类型, 默认使用的就是InnoDB.
不同存储引擎的表数据存取方式不同, 支持的功能也不同.
不同的存储引擎共用同一个Server层, 也就是从连接器到执行器的部分.

连接器

第一步, 你会先连接到这个数据库上, 这时候接待你的就是连接器. 连接器负责根客户端建立连接、获取权限、维持和管理连接. 连接命令一般是这么写的:

mysql -h$ip -P$port -u$user -p

输完命令之后, 你就会需要在交互对话里输入密码. 虽然密码也可以直接跟在-p后面写在命令行中, 但这样可能会导致你的密码泄露. 如果你连的是生产服务器, 强烈建议你不要这样做.

连接命令中的mysql是客户端工具, 用来跟服务端建立连接. 在完成经典的TCP握手后, 连接器就要开始认证你的身份, 这个时候用的就是你输入的用户名和密码.

• 如果用户名或密码不正确, 会收到一个"Access denied for user"的错误，然后客户端程序结束执行。
  
• 如果用户名密码认证通过, 连接器会到权限表里查出你拥有的权限. 之后, 这个连接里面的权限判断逻辑, 都将依赖于此时读到的权限.

这意味着, 一个用户成功建立连接后, 即使你用管理员账号对这个用户的权限做了修改, 也不会影响已经存在连接的权限. 修改完成后, 只有再新建的连接才会使用新的权限设置.

连接完成后, 如果你没有后续的动作, 这个连接就处于空闲状态, 你可以在show processlist命令中看到它.

图中的Command显示的如果是 “Sleep”, 则代表这是一个空间连接.

客户端如果太长时间没动静, 连接器就会自动将它断开. 这个时间是由参数 wait timeout 控制的, 默认值是8小时.

如果在连接被断开之后, 客户端再次发发送请求的话, 就会收到一个错误提醒 : Lost connection to MySQL server during query. 这时候如果你要继续, 就需要重连, 然后再次执行请求.
简单的说, Lost connection to MySQL server during query意思就是查询期间与MySQL服务器的连接断开.

数据库中, 长连接是指连接成功以后, 如果客户端持续有请求, 则一直使用同一个连接. 短连接则是指每次执行完很少的几次查询就断开连接, 下次查询再重新创建一个.

建立连接的过程通常是比较复杂的, 所以在使用中要尽量减少建立连接的动作, 也就是尽量使用长连接.

但是全部使用长连接后, 有时候MySQL占用内存涨得特别快, 这是因为MySQL在执行过程中临时使用的内存是管理在连接对象里面的. 这些资源会在连接断开的时候才释放. 所以如果长连接积累过多, 就可能导致内存占用太大, 被系统强行杀掉(OOM), 从现象看就是MySQL异常重启了.

如何解决上述问题, 有下面两种方案参考:

• 定期断开长连接. 使用一段时间, 或者程序里面判断执行过一个占用内存的大查询后, 断开连接, 之后要查询再重连.
• 在MySQL 5.7或以上版本中, 可以在每次执行一个比较大的操作后, 通过执行mysql_reset_connection来重新初始化连接资源. 这个过程不需要重连和重新做权限验证, 但是会将连接恢复到刚刚创建完时的状态.

查询缓存

连接建立完成后, 就可以执行SQL语句了. 执行逻辑就会来到第二步: 查询缓存.

MySQL拿到了一个查询请求后, 会先到查询缓存中看看, 之前是不是执行过这条语句. 之前执行过的语句及其结果可能会以 key-value 对的形式, 被直接缓存在内存中. key是查询的语句, value是查询的结果. 如果你的查询能够直接在这个缓存中找到key, 那么这个value就会被直接返回给客户端.

如果语句不在查询缓存中, 就会继续后面的执行阶段. 执行完成后, 执行结果会被存入查询缓存中. 理想情况下, 如果查询命中缓存, MySQL不需要执行后面的复杂操作, 就可以直接返回结果, 这个效率很高.

但是, 大多数情况下查询缓存往往是弊大于利!

查询缓存的失效非常频繁, 只要对一个表的更新, 这个表上所有的查询缓存都会被清空. 因此很可能你费劲地把结果存起来, 还没被使用, 就被一个更新全清空了. 对于更新压力大的数据库来说, 查询缓存的命中率会非常低. 除非你的业务就是有一张静态表, 很长时间才会更新一次. 比如, 一个系统配置表, 那这张表上的查询就很适合使用查询缓存.

在MySQL中可以选择是否使用查询缓存. 参数query_cache_type设置成DEMAND, 这样对于默认的SQL语句都不使用查询缓存. 而对于你确定要使用查询缓存的语句, 可以用SQL_CACHE显示指定, 像下面的SQL语句

mysql> select SQL_CACHE * from T where ID=10；

MySQL 8.0版本直接将查询缓存的整块功能删掉了

分析器

如果没有命中查询缓存, 就要开始真正执行语句了. 首先, MySQL需要知道你要做什么, 因此需要对SQL语句做解析.
分析器先会做 “词法分析”. 你输入的是由多个字符串和空格组成的一条SQL语句, MySQL需要识别出里面的字符串分别是什么, 代表什么.

MySQL从你输入的 “select” 这个关键字识别出来, 这是一个查询语句. 它也要把字符串 “T” 识别成 “表名 T”, 把字符串 “ID” 识别成 “列ID”.

做完了这些识别以后, 就要做 “语法分析”. 根据词法分析的结果, 语法分析器会根据语法规则, 判断你输入的这个SQL语句是否满足MySQL语法.

如果你的语句不对, 就会收到“You have an error in your SQL syntax”的错误提醒

一般语法错误会提示第一个出现错误的位置, 所以你要关注的是紧接着 “use naer” 的内容.

想起被编译原理支配的恐惧

优化器

经过了分析器, MySQL就知道你要做什么了. 在开始执行之前, 还要先经过优化器的处理. 优化器是在表里面有多个索引的时候, 决定使用哪个索引; 或者在一个语句有多表关联 (join) 的时候, 决定各个表的连接顺序. 比如你执行下面这样的语句, 这个语句是执行两个表的join:

mysql> select * from t1 join t2 using(ID)  where t1.c=10 and t2.d=20;

• 既可以先从表t1 里面取出c=10的记录的ID值, 再根据ID值关联到表t2, 再判断t2里面d的值是否等于20.
• 也可以先从表t2里面取出d=20的记录的ID值, 再根据ID值关联到t1, 再判断t1里面的c的值是否等于10.

这两种执行方法的逻辑结果是一样的, 但是执行的效率会有不同, 而优化器的作用就是决定选择使用哪一种方案.

优化器阶段完成后, 这个语句的执行方案就确定下来了, 然后进入执行器阶段.

关于优化器更多的详解在后面单独讲解优化器的内容.

执行器

MySQL通过分析器知道了你要做什么, 通过优化器知道了该怎么做, 于是就进入了执行器阶段, 开始执行语句.

开始执行的时候, 先要判断一下你对这个表T有没有执行查询的权限, 如果没有, 就会返回没有权限的错误, 如下所示 (在工程实现上，如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证查询也会在优化器之前调用 precheck 验证权限).
权限验证不仅仅在执行器这部分会做，在分析器之后，也就是知道了该语句要“干什么”之后，也会先做一次权限验证. 叫做precheck. 而precheck是无法对运行时涉及到的表进行权限验证的，比如使用了触发器的情况. 因此在执行器这里也要做一次执行时的权限验证.

mysql> select * from T where ID=10;

ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'

如果有权限, 就打开表继续执行. 打开表的时候, 执行器就会根据表的引擎定义, 去使用这个引擎提供的接口.
所以到了执行的时候才会进入到数据库引擎, 然后执行器也是通过调用数据库引擎的API来进行数据操作的. 也因此数据库引擎才会是插件形式的.

比如最初的例子中的表T, ID字段没有索引, 那么执行器的执行流程是这样的:

1. 调用InnoDB引擎接口取这个表的第一行, 判断ID值是不是10, 如果不是则跳过, 如果是则将这行存在结果集中;
2. 调用引擎接口取 “下一行”, 重复同样的逻辑判断, 知道取到这个表的最后一行.
3. 执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端.

至此, 这个语句就执行完成了.

对于有索引的表, 执行的逻辑也差不多. 第一次调用的是 “取满足条件的第一行” 这个接口, 之后循环取"满足条件的下一行" 这个接口, 这些接口都是引擎中已经定义好的.

你会在数据库的慢查询日志中看到一个rows_examined的字段, 表示这个语句执行过程中扫描了多少行. 这个值就是在执行器每次调用引擎获取数据行的时候累加的.

在有些场景下, 执行器调用一次, 在引擎内部则扫描了多行, 因此引擎扫描行数跟rows_examined并不是完全相同的. 在后面有一篇文章来讲存储引擎的内部机制.

小结

本文大致介绍了MySQL的逻辑框架, 对一个SQL语句完整执行流程的各个阶段有了一个初步的印象.

一个问题: 如果表 T 中没有字段 k，而你执行了这个语句 select * from T where k=1, 那肯定是会报“不存在这个列”的错误： “Unknown column ‘k’ in ‘where clause’”。你觉得这个错误是在我们上面提到的哪个阶段报出来的呢？

答案是分析器, 《高性能mysql》里提到解析器和预处理器。解析器处理语法和解析查询, 生成一课对应的解析树。预处理器进一步检查解析树的合法。比如: 数据表和数据列是否存在, 别名是否有歧义等。如果通过则生成新的解析树，再提交给优化器。
Oracle会在分析阶段判断语句是否正确，表是否存在，列是否存在等. MySQL在设计上受Oracle影响颇深. 所以也采用了同样的机制.