本周内容
1.通信方式
2.MySQL架构
3.存储引擎
4.mysql的日志系统
1. 通信方式
通信方式有三种：
单工通信：指消息只能单方向传输的工作方式。（遥控器）
半双工通信：可以实现双向的通信，但不能在两个方向上同时进行，必须轮流交替地进行。（对讲机）
全双工通信：在通信的任意时刻，线路上存在A到B和B到A的双向信号传输。（打电话）
MySQL用的是半双工通信方式
2.MySQL架构
MySQL 可以分为 Server 层和存储引擎层两部分。
- Server 层包括：连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。
- 存储引擎层：负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。
2.1 连接器
连接器:负责跟客户端建立连接、获取权限、维持和管理连接。
当客户端链接完成之后，不进行任何操作，该链接就处于sleep（空闲）状态。客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。如果在连接被断开之后，客户端再次发送请求的话，就会收到一个错误提醒： Lost connection to MySQL server during query。这时候如果你要继续，就需要重连，然后再执行请求了
show processlist的常见的几个状态值：
2.2 查询缓存
连接建立完成后，你就可以执行 select 语句了。执行逻辑就会来到第二步：查询缓存。
大多数情况下不建议使用查询缓存，因为查询缓存往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。
可以将参数 query_cache_type 设置成 DEMAND，这样对于默认的 SQL 语句都不使用查询缓存。而对于你确定要使用查询缓存的语句，可以用 SQL_CACHE 显式指定，像下面这个语句一样：
select SQL_CACHE * from T where ID=10；
MySQL 8.0 版本开始就没有这个功能了，直接将查询缓存的整块功能删掉了
2.3 分析器
分析器：主要负责词法、语法分析.
词法分析：对于SQL语句中的字符串，分析表名，列名等。
语法分析：根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。
2.4 优化器
优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。
SHOW VARIABLES LIKE 'optimizer_trace'; ---查看优化跟踪是否打开，打开之后便可以跟踪
select * from information_schema.optimizer_trace\G ---查询执行跟踪分析日志
原则是：尽可能扫描少的数据库行纪录
2.5执行器
开始执行的时候，要先判断一下你对这个表 有没有相应的权限，例如select，update等。如果没有，就会返回没有权限的错误，如下所示 (在工程实现上，如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证。查询也会在优化器之前调用 precheck 验证权限)。
如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口
3.存储引擎
不同的存储引擎，存储数据文件或存储数据的方式不同。
MyISAM
使用这个存储引擎，每个MyISAM在磁盘上存储成三个文件。
（1）frm文件：存储表的定义数据
（2）MYD文件：存放表具体记录的数据
（3）MYI文件：存储索引frm和MYI可以存放在不同的目录下。MYI文件用来存储索引，但仅保存记录所在页的指针，索引的结构是B+树结构。
innodb：
- .frm、.idb文件存储；
- 支持事务、行级锁、占用更多的空间保留数据和索引（5.5之后默认存储引擎），默认行级锁，支持表级锁
4.mysql的日志系统
4.1 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 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe（宕机恢复）。
redo log 是 InnoDB 引擎特有的日志
3.2 binlog（归档日志）
binlog（归档日志）是Server 层自己的日志。
两者区别：
- redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
- redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
- redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
redo log 和 binlog 是两个独立的逻辑，采用的是两阶段提交。如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。
- 1.update 语句时的内部流程。执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
- 2.执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
- 3.引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
- 4.执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
- 5.执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。
如果不采用两阶段提交可能产生的后果：
1.先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。
2.先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。
redo log 用于保证 crash-safe 能力，两个重要参数：
- innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
- sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。
这样就保证了，redolog跟binlog都不会丢失
