【MySQL】漫谈MySQL中的事务及其实现

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了【MySQL】漫谈MySQL中的事务及其实现，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5548字，纯文字阅读大概需要8分钟。

内容图文

为了帮助理解四种隔离级别，这里举个例子。如图1，事务A和事务B先后开启，并对数据1进行多次更新。四个小人在不同的时刻开启事务，可能看到数据1的哪些值呢？

第一个小人，可能读到1-20之间的任何一个。因为未提交读的隔离级别下，其他事务对数据的修改也是对当前事务可见的。第二个小人可能读到1，10和20，他只能读到其他事务已经提交了的数据。第三个小人读到的数据去决于自身事务开启的时间点。在事务开启时，读到的是多少，那么在事务提交之前读到的值就是多少。第四个小人，只有在A end 到B start之间开启，才有可能读到数据，而在事务A和事务B执行的期间是读不到数据的。因为第四小人读数据是需要加锁的，事务A和B执行期间，会占用数据的写锁，导致第四个小人等待锁。

疑问：当第三个小人从A执行过程中开始执行，直到事务B提交后提交，那看到的是1还是10，一直都是1？按照提交读貌似他只可以读到1，但是按照可重复读又可以读到10的样子。。。到底是怎么回事呢？

其实需要明确，RR级别一定是可以读到事务开启时已经提交的事务，未提交的当然也看不到，不然一样存在不可重复读，只是这个保障通过MVCC去实现。(如有疏漏，望君指正)

图2 罗列了不同隔离级别所面对的问题。

很显然，隔离级别越高，它所带来的资源消耗也就越大(锁)，因此它的并发性能越低。准确的说，在可串行化的隔离级别下，是没有并发的。

MySQL中的事务

事务的实现是基于数据库的存储引擎。不同的存储引擎对事务的支持程度不一样。MySQL中支持事务的存储引擎有innoDB和NDB。innoDB是MySQL默认的存储引擎，默认的隔离级别是RR，并且在RR的隔离级别下更进一步，通过多版本并发控制（MVCC，Multiversion Concurrency Control ）解决不可重复读问题，加上间隙锁（也就是并发控制）解决幻读问题。因此innoDB的RR隔离级别其实实现了串行化级别的效果，而且保留了比较好的并发性能。 事务的隔离性是通过锁实现，而事务的原子性、一致性和持久性则是通过事务日志实现。说到事务日志，不得不说的就是redo和undo。

• redo log

  在innoDB的存储引擎中，事务日志通过重做(redo)日志和innoDB存储引擎的日志缓冲(InnoDB Log Buffer)实现。事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是DBA们口中常说的“日志先行”(Write-Ahead Logging)。

  当事务提交之后，在Buffer Pool中映射的数据文件才会慢慢刷新到磁盘。此时如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据redo log中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。

  在系统启动的时候，就已经为redo log分配了一块连续的存储空间,以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。所有的事务共享redo log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起。如下一个简单示例：

    记录1：<trx1, insert...>
    记录2：<trx2, delete...>
    记录3：<trx3, update...>
    记录4：<trx1, update...>
    记录5：<trx3, insert...>

• undo log

  undo log主要为事务的回滚服务。在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。

  以下是undo+redo事务的简化过程：

  假设有2个数值，分别为A和B,值为1，2

    1. start transaction;
    2. 记录 A=1 到undo log;
    3. update A = 3；
    4. 记录 A=3 到redo log；
    5. 记录 B=2 到undo log；
    6. update B = 4；
    7. 记录B = 4 到redo log；
    8. 将redo log刷新到磁盘
    9. commit

在1-8的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。

所以，redo log其实保障的是事务的持久性和一致性，而undo log则保障了事务的原子性。

分布式事务

分布式事务的实现方式有很多，既可以采用innoDB提供的原生的事务支持，也可以采用消息队列来实现分布式事务的最终一致性。这里我们主要聊一下innoDB对分布式事务的支持。

如图，MySQL的分布式事务模型。模型中分三块：应用程序（AP）、资源管理器（RM）、事务管理器（TM）。

• 应用程序定义了事务的边界，指定需要做哪些事务；
• 资源管理器提供了访问事务的方法，通常一个数据库就是一个资源管理器；
• 事务管理器协调参与了全局事务中的各个事务。

分布式事务采用两段式提交（two-phase commit）的方式。

• 第一阶段所有的事务节点开始准备，告诉事务管理器ready。
• 第二阶段事务管理器告诉每个节点是commit还是rollback。

如果有一个节点失败，就需要全局的节点全部rollback，以此保障事务的原子性。

总结

什么时候需要使用事务呢？我想，只要业务中需要满足ACID的场景，都需要事务的支持。尤其在订单系统、银行系统中，事务是不可或缺的。

这篇文章主要介绍了事务的特性，以及MySQL innoDB对事务的支持。事务相关的知识远不止文中所说，本文仅作抛砖引玉，不足之处还望读者多多见谅。

参考文献：

• 《高性能MySQL第三版》
• 《MySQL技术内幕 innoDB存储引擎》

【MySQL】漫谈MySQL中的事务及其实现

标签：

本文系统来源：http://www.cnblogs.com/zhiqian-ali/p/5668199.html

内容总结

以上是互联网集市为您收集整理的【MySQL】漫谈MySQL中的事务及其实现全部内容，希望文章能够帮你解决【MySQL】漫谈MySQL中的事务及其实现所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端