每条 SQL 前面的数字是它的编号，4 条 SQL 分别为 SQL 1、SQL 2、SQL 3、SQL 4，其中，SQL 4 是本文的主角。
MySQL事务特性之一就是要保证原子性，一组SQL要么全部成功、要么全部失败。当事务进行过程中，如果出现失败或者异常情况要进行回滚，回到之前最初的样子，要这样实现就要需要把之前的数据记录下来。
其实，讨论MySQL的事务回滚机制，也就是在说MySQL的事务原子性是如何实现的（关于事务之前文章中有过简单介绍）。
每条 SQL 前面的数字是它的编号，9 条 SQL 分别为 SQL 1、SQL 2、...、SQL 9，其中，SQL 9 是本文的主角。
除了前两篇的日志学习，MySQL还有两个特殊的日志----回滚日志(undo log)和重做日志(redo log)，统称事务日志。 事务日志，顾名思义是为了保障数据的原子性和一致性。
redo 日志只有崩溃恢复的时候才能派上用场，undo 日志不一样，它承担着多重职责，MySQL 崩溃恢复、以及正常提供服务期间，都有它的身影。
回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志。
Redo log是事务持久性的保证，Undo log是事务原子性的保证。在事务中更新数据的前置操作其实就是要写入Undo log。
《InnoDB行锁，如何锁住一条不存在的记录？》埋了一个坑，没想到评论反响剧烈，大家都希望深挖下去。原计划写写InnoDB的锁结束这个case，既然呼声这么高，干脆全盘系统性的写写InnoDB的并发控制，锁，事务模型好了。
执行事务的时候，里面很多INSERT、UPDATE和DELETE语句都在更新缓存页里的数据，但是万一事务回滚，你必须有每条SQL语句对应的undo log回滚日志，根据回滚日志去恢复缓存页里被更新的数据。
本文想用简单精炼的语言将Innodb崩溃恢复那些事情好好拾到拾到，本文主要参考以下三本书和我个人一些感想而作:
关系型数据库中，事务的重要性不言而喻，只要对数据库稍有了解的人都知道事务具有 ACID 四个基本属性，而我们不知道的可能就是数据库是如何实现这四个属性的；在这篇文章中，我们将对事务的实现进行分析，尝试
SQL SERVER 好久没有写了，偶然有人问SQL SERVER 的UNDO REDO 怎么实现的，因为这些人不曾听说SQL SERVER 有 autovacuum ,vacuum ，也不曾听说 SQL SERVER 有UNDO 表空间，REDO 日志，到底SQL Server是怎么实现，传统数据库中需要的，前滚翻和后滚翻，我们今天看看，到底SQL SERVER 和那个数据库有近亲关系。
前面说了undo日志的文件格式，第一页和后面的页是不同的，填入undo日志之前，会先把undo_page_header属性填满，还有undo_segment_header,undo_log_header。List base node存在undo segment header，list node存在每个undo 页面的undo_page_header。
最近碰到MySQL上一个和回滚相关的问题，还需要了解其中的一些机制，尤其是Undo，GreatSQL社区的这篇文章《图文结合带你搞定MySQL日志之Undo log(回滚日志)》，能让我更多了解MySQL的Undo机制，借鉴一下。
InnoDB的已提交读和可重复读的底层实现原理：MVCC（多版本并发控制），MVCC提供了一种并发的读取方式，即快照读 ，同一份数据会有多个版本
Redo日志是Oracle为确保已经提交的事务不会丢失而建立的一种机制。实际上，Redo日志的存在是为两种场景准备的，一种称之为实例恢复（Instance Recovery），一种称之为介质恢复（Media Recovery）。
什么是事务？ 事务是一组原子性的sql语句，或者说是一个独立的工作单元。事务有四个特性，原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability)。今天想跟大家一起研究下事务内部到底是怎么实现的。
回滚和提交机制的选择取决于事务处理的需求和具体的应用场景。当事务发生错误或异常时，可以选择回滚事务来保证数据的一致性；而当事务中的所有操作都成功执行时，可以选择提交事务来实现数据的持久性和可见性。
疑问： 那读提交和可重复读有什么区别吗？ 是的，我也有这个疑问，读提交和可重复读不都是在提交后对其他事务可见。确实是这样 但是读提交在另一个事务提交后再去读取的值时则会读取到已提交事务更改的值。而可重复读是不会的。就算提交了这个事务读取也是初始读取到的值。
在微服务架构体系下，我们可以按照业务模块分层设计，单独部署，减轻了服务部署压力，也解耦了业务的耦合，避免了应用逐渐变成一个庞然怪物，从而可以轻松扩展，在某些服务出现故障时也不会影响其它服务的正常运行。总之，微服务在业务的高速发展中带给我们越来越多的优势，但是微服务并不是十全十美，因此不能盲目过度滥用，它有很多不足，而且会给系统带来一定的复杂度，其中伴随而来的分布式事务问题，是微服务架构体系下必然需要处理的一个痛点，也是业界一直关注的一个领域，因此也出现了诸如 CAP 和 BASE 等理论。
相信大家都用过事务以及了解他的特点，如原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability)等。今天想跟大家一起研究下事务内部到底是怎么实现的，在讲解前我想先抛出个问题： 事务想要做到什么效果？
本文分两部分， 第一部分概念介绍，重在理解。 第二部分通过MySQL Innodb中的具体实现，加深相关知识的印象。 本文的原意是一篇个人学习笔记，为了避免成为草草记录一下的流水账，尝试从给人介绍的角度开写。但在整理的过程中，越来越感觉力不从心，一是细节太多了，原以为足够了解的一个小知识点下可能隐藏了很多细节；二是内容与范围的取舍，既想有点技术性避免空谈，又不想陷入枯燥冗长的小细节描述。几番折腾，目前的想法把坑填上，能写完就不错了，你读起来有不顺或错误的地方请见谅，欢迎反馈。
对于“事务”，很多读者尤其是业务研发通常采用“一笔带过”的处理方式：方法上用注解声明，然后就“安心”的写代码去了。
Undo Log:数据库事务开始之前，会将要修改的记录放到Undo日志里，当事务回滚时或者数据库崩溃时，可以利用UndoLog撤销未提交事务对数据库产生的影响。
在MYSQL中，日志是非常重要的，其中Redo log 和undo log都是引擎层（innodb）实现的日志，redo log 是重做日志，提供 前滚 操作，undo log 是回退日志，提供 回滚 操作。
笔者个人项目中使用到了seata来做分布式事务管理，面试过程中也经常被问到seata的原理，seata源码本身也不是很复杂，所以准备出一个Seata源码大白话解读系列。
undo log是mysql中比较重要的事务日志之一，顾名思义，undo log是一种用于撤销回退的日志，在事务没提交之前，MySQL会先记录更新前的数据到 undo log日志文件里面，当事务回滚时或者数据库崩溃时，可以利用 undo log来进行回退。
耦合是软件不能抵御变变化的根本性原因,不仅实体对象与实体对象之间有耦合关系(如创建性设计模式存在的原因),对象和行为之间也存在耦合关系.
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
🧑个人简介：大家好，我是 shark-Gao，一个想要与大家共同进步的男人😉😉
MySQL系列会通过引擎、索引、事务、锁来说明，这篇文章讲讲基本的概念和引擎的区别。
摘录自：http://gfsunny.blog.51cto.com/990565/1566683
事务就是保证一组数据库操作要么全部成功，要么全部失败。MySQL中，事务的支持是在引擎层实现的。InnoDB支持事务，MyISAM不支持事务，这也是InnoDB逐渐取代MyISAM的原因之一。
此篇文章算是对mysql事务的一个总结，在了解这些之前我们先对mysql在执行的过程中 有一个整体的认识，如下图
MySQL 8.0开始支持原子数据定义语言（DDL）语句。此功能称为原子DDL。原子DDL语句将与DDL操作关联的数据字典更新，存储引擎操作和二进制日志写入组合到单个原子事务中。即使服务器在操作期间暂停，也会提交事务，并将适用的更改保留到数据字典，存储引擎和二进制日志，或者回滚事务。
在使用微服务时，存在跨多个服务更新数据库数据的情况。那么这就会出现一个问题，比如我们有三个服务（如下图），正常情况下，当一个请求进来时，服务1到服务3会分别改变其数据库中存储的数据，但是如果出现部分服务网络不通或者部分服务失效的情况，那么整个服务调用链就会失效，进而出现部分服务更新数据库成功，而剩余服务更新数据库失败的情况，这就出现了所谓了数据不一致。
这两个数据库操作的总和，构成一个完整的逻辑过程，不可拆分。这个过程被称为一个事务，具有ACID特性。
通过sync_binlog=1控制事件持久化到磁盘，每次事务提交时进行fsync操作，将消耗大量的磁盘IOPS，如何最大化的提高性能，降低fsync对事务高并发的影响呢？
MySQL中提供了四个事务隔离级别：读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。不同的事务隔离级别对并发访问有不同的影响。
在MySQL数据库和InnoDB存储引擎中，有很多种文件，如：参数文件、日志文件、socket文件、pid文件、MySQL表结构文件、存储引擎文件。
本文我们一起来看看，MySQL 在崩溃恢复过程中都干了哪些事情，Redo 日志又是怎么大显身手的。
Undo日志：undo log是mysql中两种比较重要的事务日志，另外一种是redo log，undo log顾名思义，是一种用于撤销回退的日志，用于事务没提交之前，会先记录存放到 Undo 日志文件里，当事务回滚时或者数据库崩溃时，可以利用 Undo 日志回退事务
一个事务执行过程中看到的数据, 总是跟这个事务在启动时看到的数据是一致的;当然在可重复读隔离级别下, 未提交变更对其他事务也是不可见的.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
