《MySQL实战45讲》学习笔记

[TOC]

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都可以用于表示事务的提交状态，需要保持逻辑上的一致。