一条更新SQL 是如何执行的?
在数据库里面,我们说的 update 操作其实包括了更新、插入和删除。更新流程和查询流程有什么不同呢?
基本流程也是一致的,也就是说,它也要经过解析器、优化器的处理,最后交给执行器。
区别就在于拿到符合条件的数据之后的操作。
首先,在 InnoDB 里面有个内存的缓冲池(buffer pool)。我们对数据的更新,不会每次都直接写到磁盘上,因为 IO 的代价太大了,所以先写入到 buffer pool 里面。内存的数据页和磁盘数据不一致的时候,我们把它叫做脏页。
InnoDB 里面有专门的把 buffer pool 的数据写入到磁盘的线程,每隔一段时间就一次性地把多个修改写入磁盘,这个就叫做刷脏。
如果在脏页还没有写入磁盘的时候,服务器出问题了,内存里面的数据丢失了。或者是刷脏刷到一半,甚至会破坏数据文件。所以我们必须要有一个持久化的机制。
redo log
InnoDB 引入了一个日志文件,叫做 redo log(重做日志),我们把所有对内存数据的修改操作写入日志文件,如果服务器出问题了,我们就从这个日志文件里面读取数据,恢复数据——用它来实现事务的持久性。
特点:
1.记录修改后的值,属于物理日志
2.redo log 的大小是固定的,前面的内容会被覆盖,所以不能用于数据回滚/数据恢复。
3.redo log 是 InnoDB 存储引擎实现的,并不是所有存储引擎都有。
binlog
MySQL Server 层也有一个日志文件,叫做 binlog,它可以被所有的存储引擎使用。
binlog 以事件的形式记录了所有的 DDL 和 DML 语句(因为它记录的是操作而不是数据值,属于逻辑日志),可以用来做主从复制和数据恢复。
主从复制
数据恢复
binlog它的文件内容是可以追加的,没有固定大小限制有了这两个日志之后,我们来看一下一条更新语句是怎么执行的:
例如一条语句:update teacher set name=‘jim’ where name =‘666’;
1、先查询到这条数据,如果有缓存,也会用到缓存。
2、把 name 改成jim,然后调用引擎的 API 接口,写入这一行数据到内存,同时记录 redo log。这时 redo log 进入 prepare 状态,然后告诉执行器,执行完成了,可以随时提交。
3、执行器收到通知后记录 binlog,然后调用存储引擎接口,设置 redo log 为 commit 状态。
4、更新完成。
问题:为什么要用两阶段提交(XA)呢?
举例:
如果我们执行的是把 name 改成jim,如果写完 redo log,还没有写 bin log 的时候,MySQL 重启了。因为 redo log 可以恢复数据,所以写入磁盘的是jim。但是 bin log 里面没有记录这个逻辑日志,所以这时候用 binlog 去恢复数据或者同步到从库,就会出现数据不一致的情况。所以在写两个日志的情况下,binlog 就充当了一个事务的协调者。通知 InnoDB 来执行 prepare 或commit 或者 rollback。简单地来说,这里有两个写日志的操作,类似于分布式事务,不用两阶段提交,就不能保证都成功或者都失败