大家好，我是 Snow Hide，作为《MySQL 实战》这个专栏的学员之一，这是我打卡的第 11 天，也是我第 57 次进行这种操作。
今天我温习了该专栏里叫《MySQL 基础架构》、《MySQL 日志系统》的文章。
关键词总结：Server 层（连接器、查询缓存、分析器、优化器、执行器、内置函数（日期、时间、数学、加密函数）、跨存储引擎功能（存储过程、触发器、视图））、存储引擎层（存储、提取、InnoDB）、重要的日志模块：redo log（所属层、WAL 技术、Redo Log、Write Pos、Checkpoint、Crash-Safe）、重要的日志模块：binlog（所属层、两种日志的三个区别点）、两阶段提交（恢复到指定的某一秒、先写 redo log 后写 binlog、先写 binlog 后写 redo log）。
所学总结：
《MySQL 基础架构》
Server 层
连接器
负责与客户端建立连接、获取权限、维持以及管理连接。
通过 mysql 客户端根据连接的过程：
- 如果用户名/密码不正确，客户端将收到错误信息 “Access denied for user” 并退出；
- 如果用户名/密码正确，连接器会通过权限表来关联用户的权限，并只让用户进行他权限范围内的操作。
对连接中的用户进行权限的变更不会使其立即生效，需要用户重新连接后才会生效。
查询缓存
查询缓存的失效非常频繁，只要表被更新，表上面所有的查询缓存都会被清空。不经常更改的表才适合使用查询缓存，例如系统配置表。MySQL 8.0 之后没有查询缓存这个模块了。
分析器
分析器会先做 “词法分析”。用户输入的是由多个字符串以及空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。
优化器
优化器是当表有多个索引时，决定使用哪个索引；或在多表关联语句时，决定表的连接顺序。
执行器
开始执行的时候，片段用户对操作表是否有对应操作类型的权限，没有则返回权限错误消息。如果有权限则打开表，执行器根据表的引擎使用相关引擎所提供的接口。
《MySQL 日志系统》
重要的日志模块：redo log
所属层
redo log 处在 InnoDB 引擎层。独有的 crash-safe 能力。
WAL 技术
WAL 的全称是 Write-Ahead Logging。它的原理是先写日志，再写磁盘。
Redo Log
当有记录需要更新时， InnoDB 引擎会先记录到 redo log （暂存）中，并更新内存，在系统空闲的时候再将记录更新至磁盘。
redo log 的大小是固定的，例如 4 个文件为一组，其中每个文件大小是 1G，可以操作的总大小是 4G。从开头至末尾循环写入。
Write Pos
当前记录的未知，写完后移至下一个位置。循环写。
Checkpoint
当前要擦除的位置，也是向后推移并循环。在擦除前需要将记录更新至数据文件。write pos 与 checkpoint 之间空着的部分是用来记录新操作的。如果 write pos 与 checkpoint 一致则表示暂存位置已满，需要擦除一些记录并将 checkpoint 推进后才能再执行更新操作。
Crash-Safe
redo log 可以确保数据库发生异常，重启后之前提交的记录依然存在，这个被称为 crash-safe（奔溃安全）。
只要记录在了暂存位置里，记录之后数据库停止运作一阵子，等启动时依然可以通过暂存位置来进行校对操作。
重要的日志模块：binlog
所属层
binlog 处在 Server 层。没有 crash-safe 能力。
两种日志的三个区别点
- redo log 为 InnoDB 引擎独有；binlog 由 MySQL 的 Server 层所实现，所有引擎均可使用；
- redo log 属于物理日志，记录语句所做的改动；binlog 则是逻辑日志，记录的是语句的原始逻辑；
- redo log 是循环写，空间可以被用完；binlog 是追加写，可以在到达指定数据量后切换至新的文件，不会覆盖原有日志。
两阶段提交
由于 redo log 与 binlog 是两个独立的逻辑，不用两阶段提交的话，只能是先写 redo log 再写 binlog，或者将操作反转。
恢复到指定的某一秒
- 找到最近的一次全量备份，将其恢复至临时库；
- 从备份的时间点开始，将备份的 binlog 依次取出并重放至误删表之前的那一时刻。
先写 redo log 后写 binlog
假设 redo log 写完，但 binlog 还未写完时，MySQL 进程发生异常。由于 redo log 已写完，即使系统奔溃，我们仍然能将数据恢复。但是 binlog 就不会存在该语句逻辑的记录。此时，redo log 里的数据是新的，而 binlog 里的语句逻辑记录则是旧的。
先写 binlog 后写 redo log
倘若 binlog 写完，但 redo log 还未写完时，在奔溃重启后，该事务不成立。此时，binlog 里的语句逻辑记录是新的，而 redo log 里的物理数据则是旧的。
末了
重新总结了一下文中提到的内容：MySQL 逻辑架构、SQL 语句完整执行流程、redo log 物理日志、binlog 逻辑日志、redo log 保证 crash-safe 特性需要配置的参数、日志系统的两阶段提交、跨系统维持数据逻辑一致性方案。
