217217
218218` binlog ` (归档日志)保证了` MySQL ` 集群架构的数据一致性。
219219
220- 虽然它们都属于持久化的保证,但是则重点不同 。
220+ 虽然它们都属于持久化的保证,但是侧重点不同 。
221221
222222在执行更新语句过程,会记录` redo log ` 与` binlog ` 两块日志,以基本的事务为单位,` redo log ` 在事务执行过程中可以不断写入,而` binlog ` 只有在提交事务时才写入,所以` redo log ` 与` binlog ` 的写入时机不一样。
223223
255255
256256> 这部分内容为 JavaGuide 的补充:
257257
258- 我们知道如果想要保证事务的原子性,就需要在异常发生时,对已经执行的操作进行** 回滚** ,在 MySQL 中,恢复机制是通过 ** 回滚日志(undo log)** 实现的,所有事务进行的修改都会先先记录到这个回滚日志中 ,然后再执行相关的操作。如果执行过程中遇到异常的话,我们直接利用 ** 回滚日志** 中的信息将数据回滚到修改之前的样子即可!并且,回滚日志会先于数据持久化到磁盘上。这样就保证了即使遇到数据库突然宕机等情况,当用户再次启动数据库的时候,数据库还能够通过查询回滚日志来回滚将之前未完成的事务。
258+ 我们知道如果想要保证事务的原子性,就需要在异常发生时,对已经执行的操作进行** 回滚** ,在 MySQL 中,恢复机制是通过 ** 回滚日志(undo log)** 实现的,所有事务进行的修改都会先记录到这个回滚日志中 ,然后再执行相关的操作。如果执行过程中遇到异常的话,我们直接利用 ** 回滚日志** 中的信息将数据回滚到修改之前的样子即可!并且,回滚日志会先于数据持久化到磁盘上。这样就保证了即使遇到数据库突然宕机等情况,当用户再次启动数据库的时候,数据库还能够通过查询回滚日志来回滚将之前未完成的事务。
259259
260260另外,` MVCC ` 的实现依赖于:** 隐藏字段、Read View、undo log** 。在内部实现中,` InnoDB ` 通过数据行的 ` DB_TRX_ID ` 和 ` Read View ` 来判断数据的可见性,如不可见,则通过数据行的 ` DB_ROLL_PTR ` 找到 ` undo log ` 中的历史版本。每个事务读到的数据版本可能是不一样的,在同一个事务中,用户只能看到该事务创建 ` Read View ` 之前已经提交的修改和该事务本身做的修改
261261
@@ -277,4 +277,4 @@ MySQL InnoDB 引擎使用 **redo log(重做日志)** 保证事务的**持久性*
277277## MySQL 好文推荐
278278
279279- [ CURD 这么多年,你有了解过 MySQL 的架构设计吗?] ( https://mp.weixin.qq.com/s/R-1km7r0z3oWfwYQV8iiqA )
280- - [ 浅谈 MySQL InnoDB 的内存组件] ( https://mp.weixin.qq.com/s/7Kab4IQsNcU_bZdbv_MuOg )
280+ - [ 浅谈 MySQL InnoDB 的内存组件] ( https://mp.weixin.qq.com/s/7Kab4IQsNcU_bZdbv_MuOg )
0 commit comments