年前Mysql实践三部曲（一）.docxVIP

年前Mysql实践三部曲（一） 2021-01-28 基础架构：一条 SQL 查询语句是如何执行的？ MySQL 的基本架构示意图： MySQL 可以分为 Server 层和存储引擎层两部分。 Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及全部的内置函数（如日期、时间、数学和加密函数等），全部跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。 存储引擎层担任数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开头成为了默认存储引擎。 不同存储引擎的表数据存取方式不同，支持的功能也不同。不同的存储引擎共用一个Server 层，也就是从连接器到执行器的部分。 连接器 连接器担任跟客户端建立连接、猎取权限、维持和管理连接。 查询缓存 MySQL 拿到一个查询恳求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的方式，被直接缓存在内存中。key 是查询的语句，value 是查询的结果。假如你的查询能够直接在这个缓存中找到 key，那么这个 value 就会被直接前往给客户端。 但是大多数情况下我会建议你不要使用查询缓存，为什么呢？由于查询缓存往往弊大于利。 查询缓存的失效格外频繁，只需有对一个表的更新，这个表上全部的查询缓存都会被清空。因而很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会格外低。除非你的业务就是有一张静态表，很长时间才会更新一次。比如，一个系统配置表，那这张表上的查询才适合使用查询缓存。 MySQL 8.0 版本直接将查询缓存的整块功能删掉了，也就是说 8.0 开头彻底没有这个功能了。 分析器 假如没有命中查询缓存，就要开头真正执行语句了。 分析器先会做“词法分析”。做完了这些识别以后，就要做“语法分析”。 优化器 优化器是在表里面有多个索引的时候，打算使用哪个索引；或者在一个语句有多表关联（join）的时候，打算各个表的连接挨次。 优化器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。 执行器 打开表的时候，执行器就会依据表的引擎定义，去使用这个引擎供应的接口。 你会在数据库的慢查询日志中看到一个 rows_examined 的字段，表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎猎取数据行的时候累加的。 在有些场景下，执行器调用一次，在引擎内部则扫描了多行，因而引擎扫描行数跟 rows_examined 并不是完全相同的。 我给你留一个问题吧，假如表 T 中没有字段 k，而你执行了这个语句 select * from T where k=1, 那确定是会报“不存在这个列”的错误： “Unknown column ‘k’ in ‘where clause’”。你觉得这个错误是在我们上面提到的哪个阶段报出来的呢？ 答案是分析器。 日志系统：一条 SQL 更新语句是如何执行的？ 与查询流程不一样的是，更新流程还涉及两个重要的日志模块，它们正是我们今日要争辩的配角：redo log（重做日志）和 binlog（归档日志）。 重要的日志模块：redo log MySQL 里经常说到的 WAL 技术，WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。 具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉板）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。 与此类似，InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开头写，写到末尾就又回到开头循环写。 write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。 write pos 和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。假如 write pos 追上 checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推动一下。 有了 redo log，InnoDB 就可以保证即便数据库发生特别重启，