《MySQL实战45讲》学习笔记
《MySQL实战45讲》学习笔记
[TOC]
《MySQL实战45讲》学习笔记
- 《MySQL实战45讲》学习笔记
- 01.基础架构：一条SQL查询语句是如何执行的
- 02.日志系统：一条SQL更新语句是如何执行的
- 更新语句的执行流程
- 重要的日志模块：redo log
- 重要的日志模块：binlog
- 两阶段提交
01.基础架构：一条SQL查询语句是如何执行的
MySQL基本架构示意图：
以以下语句为例：
SELECT * FROM T WHAERE ID = 10;
02.日志系统：一条SQL更新语句是如何执行的
Mysql可以恢复半个月内任意1秒的状态。
更新语句的执行流程
以一条更新语句为例：
CREATE TABLE T(ID int primary key,c int);
UPDATE T SET c=c+1 WHERE ID = 2;
更新语句的执行路径和查询语句类似：
-
执行语句前先连接数据库
-
更新表会清空所有查询缓存。因此不建议使用查询缓存。
-
分析器知道这是一条更新语句，优化器使用ID这个索引，执行器负责找到这一行然后更新。
与查询流程不同的是更新流程设计两个重要日志模块：redo log（重做日志）和binlog（归档日志）。
重要的日志模块：redo log
在MySQl中，如果每一次更新都写进磁盘，磁盘再去找对应的记录再更新，会耗费很大的IO成本、查找成本，所以MySQL使用WAL（Write Ahead Logging)技术，先写日志，再写磁盘。
具体为 当一条记录需要更新时，InnoDB引擎把记录先写到REDO LOG中并更新内存；在适当的时候InnoDB引擎将该操作记录到磁盘中，一般是系统空闲时。
注意：InnoDB的redo log大小固定。从头开始写，写到末尾又回到开头循环写。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bUm3u9LW-1670140687147)(https://raw.githubusercontent.com/principlepeggy/imgForBlog/master/redolog-%E7%AC%AC%202%20%E9%A1%B5.drawio.png)]
write_pos:当前记录的位置，边写边后移且循环。
checkpoint:当前要擦除的位置，向后移且循环。
他们之间时可以用来记录操作的空闲部分。当write_pos = checkpoint时，不能执行新更新，停下擦除一些记录，推进checkpoint。
crash-safe: 数据库发生异常重启，之前提交的记录都不会丢失。
重要的日志模块：binlog
redo log是InnoDB特有的日志，binlog是server层的日志。
| redo log | binlog |
|---|---|
| InnoDB特有 | 所有引擎都可以使用 |
| 物理日志：“在某数据页做了某修改” | 逻辑日志：“给某行某字段+1” |
| 循环写，空间固定会用完 | 追加写，写到一定大小后切换到下一个，不会覆盖之前的日志 |
| UPDATE语句的执行流程图： |
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sA6zjUZL-1670140687148)(https://raw.githubusercontent.com/principlepeggy/imgForBlog/master/redolog-%E7%AC%AC%203%20%E9%A1%B5.png)]
深色是在执行器中执行的，浅色框是在InnoDB内部执行的。
两阶段提交
redo log的写入拆成了两个步骤：prepare和 commit。这就是两阶段提交，为了让两份日志的逻辑一致。
数据库恢复到半月前的任意一秒的状态：
找到最近的一次全量备份，从该备份恢复到临时库；从备份时间点开始，将备份的binlog取出，重放到想要恢复的那个时刻。此时临时库和彼时的线上库一致。
不使用两阶段提交的后果：
若写完第一个日志后，第二个日志写期间发生crash：
1.先写redo log ，后写binlog；恢复后无binlog的逻辑操作；
2.先写binlog，后写redolog；恢复后多了binlog的事务。
以上都是数据库的状态和用他的日志恢复出来的库状态不一致。
恢复数据在误操作时，及扩容时都会应用。
扩容的常用方法：全量备份加应用binlog实现。
redolog 和binlog都可以用于表示事务的提交状态，需要保持逻辑上的一致。