执行一条语句，要么全部成功、否则全部失败，不会产生部分成功的情况，主要是指修改、删除语句，例如DELETE FROM TEST，当删除一部分的时候遇到问题会取消操作，一条也不删除。
创新互联专注于企业营销型网站建设、网站重做改版、江津网站定制设计、自适应品牌网站建设、H5开发、商城网站建设、集团公司官网建设、外贸网站建设、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为江津等各大城市提供网站开发制作服务。
undolog可以实现事务的原子性，还可以用来实现MVCC。其原理是，（开启事务后）在操作任何数据前，先将原数据备份到undolog，然后对数据进行修改，如果此过程中出现异常，或执行了rollback语句，可利用undolog中备份的数据恢复到事务开始之前的状态。
假设有A、B两个数据，值分别为1,2。 进行+2的事务操作。
A.事务开始.
B.记录A=1到undo log.
C.修改A=3.
D.记录B=2到undo log.
E.修改B=4.
F.将undo log写到磁盘。
G.将数据写到磁盘。
H.事务提交
对于数据的操作，都是先读到内存中，然后在内存中修改，最后将数据写到磁盘。
之所以能保证原子性，是因为：
A. 更新数据前记录Undo log。
B. 为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。
C. Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃，undo log是完整的,可以用来回滚事务。
D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。
缺点：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。
所以，为了提升性能，可以在写数据到磁盘前，先写redolog，这就是wal预写日志机制，这样先写redolog日志，数据只需先写到内存，因为redolog是顺序写，而数据落盘则是随机写，要慢得多。 这样，当系统崩溃时，虽然数据没有持久化，但有redolog撑着，数据也不会丢。（innodb_flush_log_at_trx_commit 这个参数设置为2时，那么redolog每次不需落盘，而是写到os cache中（一定时间后再flush到磁盘），这样性能又大大提升，只要操作系统不宕，即便mysql宕了，数据也不会丢）
Undo + Redo事务的简化过程
A.事务开始.
B.记录A=1到undo log.
C.修改A=3.
D.记录A=3到redo log.
E.记录B=2到undo log.
F.修改B=4.
G.记录B=4到redo log.
H.将redo log写入磁盘。
I.事务提交
通过undo保证事务的原子性，redo保证持久性。
但是！！！基于以上的过程，mysql一个事务操作依旧十分繁琐，这也就是其在并发场景下需借助于nosql来提升性能
redolog和undolog属于innodb，而在mysql的server层还有一个binlog，其作用是误操作后需要靠它来恢复数据以及主从复制， mysql在update一行数据的时候：
1.执行器先找引擎取id=n这一行，id是主键，引擎直接用树搜索到这一行
2.执行器拿到引擎给的行数据，把这个值加1，得到新的一行数据，再调用引擎接口写入这行新数据
3.引擎将这行数据更新到内存中，同时将这个更新操作记录到redolog中，此时redolog处于prepare状态，然后告知执行器执行完成，随时可以提交事务
4.执行器生成这个操作的binlig，并写入磁盘
5.执行器调用引擎的提交事务接口，引擎吧刚刚写入的redolog改成提交（commit）状态，更新完成
将redolog的写入拆成两个步骤，prepare和commit，这就是两阶段提交，其目的是为了让两份日志（redolog和binlog）之间的逻辑一致
这两个日志有三点不同：
1.redolog是innodb特有，binlog是mysql server层实现的，所有引擎都可以使用，
2.redolog是物理日志，记录的是在某个数据页上做了什么修改，binlog是逻辑日志，记录的是这个语句的原始逻辑，
3.redolog是循环写的，空间固定会用完，binlog是可以追加写入的，追加写是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
redolog和binlog互相是不可替代的，redolog的作用是提升数据写入时的性能，并保证事务的持久化特性，以及崩溃恢复的能力，而binlog 是无法支持崩溃恢复，因为它没有能力恢复“数据页”。 而binlog也有着redolog无法替代的功能，一个是归档。redo log 是循环写，写到末尾是要回到开头继续写的。这样历史日志没法保留，redolog 也就起不到归档的作用。还有很多公司有异构系统中使用到的组件（比如es，redis等），这些系统就靠消费 MySQL 的 binlog 来更新自己的数据。关掉 binlog 的话，这些下游系统就没法输入了。总之，由于现在包括 MySQL 高可用在内的很多系统机制都依赖于 binlog，所以“鸠占鹊巢”redo log 还做不到。
1、原子性（Atomicity）原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
2、 一致性（Consistency）一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
3、隔离性（Isolation）隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
4、持久性（Durability）持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
扩展资料
MyISAMMySQL5.0之前的默认数据库引擎，最为常用。拥有较高的插入，查询速度，但不支持事务InnoDB事务型数据库的首选引擎，支持ACID事务，支持行级锁定，MySQL5.5起成为默认数据库引擎BDB源自BerkeleyDB，事务型数据库的另一种选择，支持Commit和Rollback等其他事务特性Memory所有数据置于内存的存储引擎，拥有极高的插入，更新和查询效率。
但是会占用和数据量成正比的内存空间。并且其内容会在MySQL重新启动时丢失Merge将一定数量的MyISAM表联合而成一个整体，在超大规模数据存储时很有用Archive非常适合存储大量的独立的，作为历史记录的数据。
因为它们不经常被读取。Archive拥有高效的插入速度，但其对查询的支持相对较差Federated将不同的MySQL服务器联合起来，逻辑上组成一个完整的数据库。非常适合分布式应用Cluster/NDB高冗余的存储引擎，用多台数据机器联合提供服务以提高整体性能和安全性。适合数据量大，安全和性能要求高的应用
原子性， 一个事务 要么完全提交 要么完全回滚，不会介于2者之间。 一致性，一个查询发起后，不管数据发生了多少变化 多少事务，查询结果应当为发起查询时间一致的数据