精华内容
下载资源
问答
  • 事务原子性
    2019-09-15 13:02:03

    其实一致性和原子性在事务里是两个不太相关,但又很相关的逻辑来的

    原子性:这个侧重点是事务执行的完整,一套事务下来,如果有一个失败,那整体失败。也就是要么大家一起成功,要么全都回滚。

    一致性:这个侧重点是业务逻辑和规则,一致性的核心一部分是靠原子性实现的,而另一部分是逻辑实现。

    举个例子吧:
    转账:张三给李四转账100元。那数据库假设需要张三扣100,李四加100,记录一条流水。
    如果流水没记录成功,那整体回滚,张三也没转账成功,李四也没多钱。这就是原子性的体现。

    而张三必须扣100,李四必须加100,这个就是一致性了,如果因为某些逻辑原因,导致张三扣了100,流水记录100转账,而李四只加了60。然后这3条操作都成功了,那原子性就符合了,但是一致性就不符合了

    其实在实际应用中肯定不是这么简单的例子的。往往是类似,买东西扣库存这类的逻辑,主表里有库存,库存表里有库存,然后就因为设计缺陷,就算加了事务还是出现了主表库存对不上库存表库存的问题,这个就是一致性不满足的了。

    更多相关内容
  • 原子性是指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作执行都成功,才算整个事务成功。如果事务中任何一个SQL语句执行失败,那么已经执行成功的SQL语句也必须撤销,数据库状态应该退回到执行...

    前言

    大家都知道事务有四个特性:

    • 原子性(atomicity)

      原子性是指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作执行都成功,才算整个事务成功。如果事务中任何一个SQL语句执行失败,那么已经执行成功的SQL语句也必须撤销,数据库状态应该退回到执行事务前的状态。

    • 一致性(consistency)

      一致性指事务将数据库从一种状态转变为下一种一致的状态。在事务开始之前和事务结束以后,数据库的完整性约束没有被破坏。

    • 隔离性(isolation)

      一个事务的影响在该事务提交前对其他事务都不可见——这通过锁来实现。

    • 持久性(durability)

      事务一旦提交,其结果就是永久性的。即使发生宕机等故障,数据库也能将数据恢复。

    对于隔离性的实现,可以参考我的这篇文章:InnoDB锁与事务简析

    本篇文章主要讲述其它三个特性是如何实现的:通过数据库的redo和undo来完成。本文如果不做特别说明,默认指的是mysql的InnoDB存储引擎。

    实现

    基础知识

    1. redo log记录的关于每个页(Page)的更改的物理情况
    2. undo log和redo log记录物理日志不一样,它是逻辑日志。可以认为当delete一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当update一条记录时,它记录一条对应相反的update记录。
    3. LSN称为日志的逻辑序列号(log sequence number),在innodb存储引擎中,lsn占用8个字节。LSN的值会随着日志的写入而逐渐增大。事务中更新操作会产生一个新的LSN。LSN不仅存在于redo log中,还存在于数据页中。
    4. checkpoint检查点,表示脏页写入到磁盘的时候

    整体流程

    在这里插入图片描述
    无论是日志还是数据,都是现在buffer里修改,然后再同步到磁盘上的。

    1. 启动事务后,修改的数据如果没有在log buffer中,则会从磁盘读取到log buffer

    2. 对内存中数据修改之前,将原始数据记录到undo log

    3. 对内存中的数据页进行修改,在内存数据页中记录LSN,暂且称之为data_in_buffer_lsn

    4. 在修改数据页的同时(几乎是同时)向redo log in buffer中写入redo log,并记录下对应的LSN,暂且称之为redo_log_in_buffer_lsn;

    5. 日志刷盘和数据刷盘

      日志刷盘的规则为

      • 发出commit动作时

      • 每秒刷一次

      • 当log buffer中已经使用的内存超过一半时

      • 当有checkpoint时

      数据刷盘的规则为

      • 当有checkpoint时

      日志刷盘的次数比数据刷盘次数更多,另外即使在checkpoint时,innoDB也会**保证在写数据前,需要先写日志,这种方式称为预写日志方式(Write-Ahead Logging,WAL)。**InnoDB存储引擎通过预写日志的方式来保证事务的完整性。

      预写日志方式之所以能保证完整性,是因为日志和数据页中有LSN,通过LSN可以比较日志和数据页中数据记录的顺序。日志文件是真正的核心。

    实例

    来源于:详细分析MySQL事务日志(redo log和undo log)

    在这里插入图片描述
    上图中,从上到下的横线分别代表:时间轴、buffer中数据页中记录的LSN(data_in_buffer_lsn)、磁盘中数据页中记录的LSN(data_page_on_disk_lsn)、buffer中重做日志记录的LSN(redo_log_in_buffer_lsn)、磁盘中重做日志文件中记录的LSN(redo_log_on_disk_lsn)以及检查点记录的LSN(checkpoint_lsn)。

    假设在最初时(12:0:00)所有的日志页和数据页都完成了刷盘,也记录好了检查点的LSN,这时它们的LSN都是完全一致的。

    假设此时开启了一个事务,并立刻执行了一个update操作,执行完成后,buffer中的数据页和redo log都记录好了更新后的LSN值,假设为110。这时候如果执行 show engine innodb status 查看各LSN的值,即图中①处的位置状态,结果会是:

    log sequence number(110) > log flushed up to(100) = pages flushed up to = last checkpoint at
    

    之后又执行了一个delete语句,LSN增长到150。等到12:00:01时,触发redo log刷盘的规则(其中有一个规则是 innodb_flush_log_at_timeout 控制的默认日志刷盘频率为1秒),这时redo log file on disk中的LSN会更新到和redo log in buffer的LSN一样,所以都等于150,这时 show engine innodb status ,即图中②的位置,结果将会是:

    log sequence number(150) = log flushed up to > pages flushed up to(100) = last checkpoint at
    

    再之后,执行了一个update语句,缓存中的LSN将增长到300,即图中③的位置。

    假设随后检查点出现,即图中④的位置,正如前面所说,检查点会触发数据页和日志页刷盘,但需要一定的时间来完成,所以在数据页刷盘还未完成时,检查点的LSN还是上一次检查点的LSN,但此时磁盘上数据页和日志页的LSN已经增长了,即:

    log sequence number > log flushed up to 和 pages flushed up to > last checkpoint at
    

    但是log flushed up to和pages flushed up to的大小无法确定,因为日志刷盘可能快于数据刷盘,也可能等于,还可能是慢于。但是checkpoint机制有保护数据刷盘速度是慢于日志刷盘的:当数据刷盘速度超过日志刷盘时,将会暂时停止数据刷盘,等待日志刷盘进度超过数据刷盘。

    等到数据页和日志页刷盘完毕,即到了位置⑤的时候,所有的LSN都等于300。

    随着时间的推移到了12:00:02,即图中位置⑥,又触发了日志刷盘的规则,但此时buffer中的日志LSN和磁盘中的日志LSN是一致的,所以不执行日志刷盘,即此时 show engine innodb status 时各种lsn都相等。

    随后执行了一个insert语句,假设buffer中的LSN增长到了800,即图中位置⑦。此时各种LSN的大小和位置①时一样。

    随后执行了提交动作,即位置⑧。默认情况下,提交动作会触发日志刷盘,但不会触发数据刷盘,所以 show engine innodb status 的结果是:

    log sequence number = log flushed up to > pages flushed up to = last checkpoint at
    

    最后随着时间的推移,检查点再次出现,即图中位置⑨。但是这次检查点不会触发日志刷盘,因为日志的LSN在检查点出现之前已经同步了。假设这次数据刷盘速度极快,快到一瞬间内完成而无法捕捉到状态的变化,这时 show engine innodb status 的结果将是各种LSN相等。

    恢复

    mysql的恢复策略是:

    1. 恢复时,先根据redo重做所有事务,包括未提交的事务
    2. 再根据undo回滚未提交的事务。

    通过这种策略,保证了事务的原子性、一致性和持久性。

    另外,引入了checkpoint机制,在恢复的时候,只需要从checkpoint的位置往后恢复即可

    感想

    1. 网络上很多的内容可能不准确,即使是我写的这篇文章,也可能有不准确的地方,解决这个问题的最好办法是读源码
    2. 不同的技术可能实现不同,但核心原理往往都是相通的,而这些核心原理一般建立在基础知识之上
    3. 学习知识可以学习到不同的深度,看完《MySQL技术内幕:InnoDB存储引擎》便能大体掌握mysql的使用,但是了解的不深入,随着写了这两篇文章,对Mysql的了解更加深入了一些,如果需要继续深入,真的需要看源码了,这个事情感觉得耗费更多的时间。所以需要知道自己需要了解到什么水平,用有限的时间去做性价比更高的事情,选择很重要。

    资料

    1. 深入学习MySQL事务:ACID特性的实现原理
    2. 详细分析MySQL事务日志(redo log和undo log)
    3. https://blog.csdn.net/suerge_storm/article/details/90484944
    4. https://blog.csdn.net/qq_41151659/article/details/99559397

    最后

    大家如果喜欢我的文章,可以关注我的公众号(程序员麻辣烫)

    往期文章回顾:

    1. 事务原子性、一致性、持久性的实现原理
    2. 如何锻炼自己的记忆力
    3. CDN请求过程详解
    4. 关于程序员职业发展的思考
    5. 记博客服务被压垮的历程
    6. 常用缓存技巧
    7. 如何高效对接第三方支付
    8. Gin框架简洁版
    9. 关于代码review的思考
    10. InnoDB锁与事务简析
    11. Markdown编辑器推荐-typora
    展开全文
  • 数据库事务原子性、一致性是怎样实现的? atomicity/consistency 数据库的一致性依赖于其他三种特性:原子性,隔离性,持久性 原子性用于保证事务中的语句要么全部执行要么全部不执行 隔离性用于保证多事务并发处理...

    数据库事务原子性、一致性是怎样实现的?

    atomicity/consistency

    数据库的一致性依赖于其他三种特性:原子性,隔离性,持久性

    原子性用于保证事务中的语句要么全部执行要么全部不执行

    隔离性用于保证多事务并发处理下事务处理顺序与结果的保证

    隔离性的处理分为四个级别

    • read uncommit ted
    • read committed
    • repeatable read
    • serializable

    原子性如何保证

    atomicity

    innodb使用undo log

    回滚日志,记录事务操作以便回滚

    • insert->delete
    • delete->insert
    • update->update 更新的回滚就先记录更改前的数据然后回滚就跟新为之前的状态

    使用undo log撤回之前的操作

    持久性如何保证

    durability

    redo log

    Mysql是先把磁盘上的数据加载到内存中,在内存中对数据进行修改,再刷回磁盘上。如果此时突然宕机,内存中的数据就会丢失。

    怎么解决?

    事务提交前直接把数据写入磁盘

    太浪费IO资源

    使用redo log来解决持久性和读写IO消耗严重问题

    当做数据修改的时候,不仅在内存中操作,还会在redo log中记录这次操作。当事务提交的时候,会将redo log日志进行刷盘(redo log一部分在内存一部分在磁盘)。当数据库宕机重启会将redolog中的内容恢复到数据库再根据undo log和binlog内容决定回滚数据还是提交数据

    隔离性如何保证?

    isolation

    使用锁机制,保证每个事务能够看到的数据总是一致的,就好像其他事务不存在一样,多个事务并发执行后的状态和它们串行执行后的状态是等价的

    两种锁

    • 悲观锁

      当前事务设计操作的对象加锁,操作完成后释放给其它对象使用。

      提高性能->{各种粒度:数据库/表/行/各种性质:共享/排他/共享意向/排他意向/共享排他意向}

      解决死锁->{两阶段协议/死锁检测}

    • 乐观锁

      不同事物可同时可能到同一对象的不同历史版本。使用MVCC(多版本并发控制,Multi-Version Concurrency Control),可在事务提交前查看修改事务的版本,如果与读取版本不一致可放弃提交

      如果有两个事务同时修改了同一数据行,那么在较晚的事务提交时进行冲突检测。实现:通过undo log来获取历史版本,另一种简单地在内存中保存同一数据行的多个历史版本,通过时间戳来区分。

    展开全文
  • 分布式应用保证事务原子性方案

    千次阅读 2016-09-01 14:09:45
    我们经常使用事务来保证数据库层面数据的ACID特性。 举个栗子,用户下了一个订单,需要修改余额表,订单表,流水表,于是会有类似的伪代码: start transaction;  CURDtable t_account; any Exception ...

    一、案例缘起

    我们经常使用事务来保证数据库层面数据的ACID特性。

    举个栗子,用户下了一个订单,需要修改余额表,订单表,流水表,于是会有类似的伪代码:

    start transaction;

             CURDtable t_account;  any Exception rollback;

             CURDtable t_order;       any Exceptionrollback;

             CURDtable t_flow;         any Exceptionrollback;

    commit;

    如果对余额表,订单表,流水表的SQL操作全部成功,则全部提交,如果任何一个出现问题,则全部回滚,以保证数据的一致性。

     

    互联网的业务特点,数据量较大,并发量较大,经常使用拆库的方式提升系统的性能。如果进行了拆库,余额、订单、流水可能分布在不同的数据库上,甚至不同的数据库实例上,此时就不能用事务来保证数据的一致性了。这种情况下如何保证数据的一致性,是今天要讨论的话题。

     

    二、补偿事务

    补偿事务是一种在业务端实施业务逆向操作事务,来保证业务数据一致性的方式。

    举个栗子,修改余额表事务为

    int Do_AccountT(uid, money){

    start transaction;

             //余额改变money这么多

             CURDtable t_account with money;       anyException rollback return NO;

    commit;

    return YES;

    }

     

    那么补偿事务可以是:

    int Compensate_AccountT(uid, money){

             //做一个money的反向操作

             returnDo_AccountT(uid, -1*money){

    }

     

    同理,订单表操作为

    Do_OrderT,新增一个订单

    Compensate_OrderT,删除一个订单

     

    要保重余额与订单的一致性,可能要写这样的代码:

    // 执行第一个事务

    int flag = Do_AccountT();

    if(flag=YES){

             //第一个事务成功,则执行第二个事务

             flag= Do_OrderT();

             if(flag=YES){

                      // 第二个事务成功,则成功

                       returnYES;

    }

    else{

             // 第二个事务失败,执行第一个事务的补偿事务

             Compensate_AccountT();

    }

    }

     

    该方案的不足是:

    1不同的业务要写不同的补偿事务,不具备通用性

    2)没有考虑补偿事务的失败

    3如果业务流程很复杂,if/else会嵌套非常多层

     

    例如,如果上面的例子加上流水表的修改,加上Do_FlowTCompensate_FlowT,可能会变成一个这样的if/else

    // 执行第一个事务

    int flag = Do_AccountT();

    if(flag=YES){

             //第一个事务成功,则执行第二个事务

             flag= Do_OrderT();

             if(flag=YES){

                      // 第二个事务成功,则执行第三个事务

                       flag= Do_FlowT();

                       if(flag=YES){

                                //第三个事务成功,则成功

                                returnYES;

    }

    else{

             // 第三个事务失败,则执行第二、第一个事务的补偿事务

             flag =Compensate_OrderT();

             if … else … // 补偿事务执行失败?

                      flag= Compensate_AccountT();

                       if … else … // 补偿事务执行失败?

    }

    }

    else{

             // 第二个事务失败,执行第一个事务的补偿事务

             Compensate_AccountT();

             if … else … // 补偿事务执行失败?

    }

    }

     

    三、事务拆分分析与后置提交优化

    单库是用这样一个大事务保证一致性:

    start transaction;

             CURDtable t_account;  any Exception rollback;

             CURDtable t_order;       any Exceptionrollback;

             CURDtable t_flow;         any Exceptionrollback;

    commit;

    拆分成了多个库,大事务会变成三个小事务:

    start transaction1;

             //第一个库事务执行

             CURDtable t_account;  any Exception rollback;

             …

    // 第一个库事务提交

    commit1;

    start transaction2;

             //第二个库事务执行

             CURDtable t_order;       any Exceptionrollback;

             …

    // 第二个库事务提交

    commit2;

    start transaction3;

             //第三个库事务执行

             CURDtable t_flow;         any Exceptionrollback;

             …

    // 第三个库事务提交

    commit3;

     

    一个事务,分成执行与提交两个阶段,执行的时间其实是很长的,而commit的执行其实是很快的,于是整个执行过程的时间轴如下:


    第一个事务执行200ms,提交1ms

    第二个事务执行120ms,提交1ms

    第三个事务执行80ms,提交1ms

    那在什么时候系统出现问题,会出现不一致呢?

    回答第一个事务成功提交之后,最后一个事务成功提交之前,如果出现问题(例如服务器重启,数据库异常等),都可能导致数据不一致。


     

    如果改变事务执行与提交的时序,变成事务先执行,最后一起提交,情况会变成什么样呢:


    第一个事务执行200ms

    第二个事务执行120ms

    第三个事务执行80ms

    第一个事务执行1ms

    第二个事务执行1ms

    第三个事务执行1ms

     

    那在什么时候系统出现问题,会出现不一致呢?

    问题的答案与之前相同:第一个事务成功提交之后,最后一个事务成功提交之前,如果出现问题(例如服务器重启,数据库异常等),都可能导致数据不一致。


     

    这个变化的意义是什么呢?

    方案一总执行时间是303ms,最后202ms内出现异常都可能导致不一致;

    方案二总执行时间也是303ms,但最后2ms内出现异常才会导致不一致;

    虽然没有彻底解决数据的一致性问题,但不一致出现的概率大大降低了!

     

    事务提交后置降低了数据不一致的出现概率,会带来什么副作用呢?

    回答:事务提交时会释放数据库的连接,第一种方案,第一个库事务提交,数据库连接就释放了,后置事务提交的方案,所有库的连接,要等到所有事务执行完才释放。这就意味着,数据库连接占用的时间增长了,系统整体的吞吐量降低了。

     

    四、总结

    trx1.exec();

    trx1.commit();

    trx2.exec();

    trx2.commit();

    trx3.exec();

    trx3.commit();

    优化为:

    trx1.exec();

    trx2.exec();

    trx3.exec();

    trx1.commit();

    trx2.commit();

    trx3.commit();

    这个小小的改动(改动成本极低),不能彻底解决多库分布式事务数据一致性问题,但能大大降低数据不一致的概率,带来的副作用是数据库连接占用时间会增长,吞吐量会降低。对于一致性与吞吐量的折衷,还需要业务架构师谨慎权衡折衷。

    展开全文
  • 一、Redis 事务的实现原理 一个事务从开始到结束通常会经历以下三个阶段: 1、事务开始 客户端发送 MULTI 命令,服务器执行 MULTI 命令逻辑。 服务器会在客户端状态(redisClient)的 flags 属性打开 REDIS_MULTI ...
  • 事务的特性——原子性(实现原理) 事务的原子性是指一个事务中的所有操作是不可分割的,必须是一个逻辑单元,只能是全部执行成功或者全部执行失败。(典型例子:转账)。那么事务的原子性是如何...事务原子性是如何
  • 数据库的事务必须满足4个特性:原子性, 一致性, 隔离性, 持久性,它们英文单词首字母合起来就是:ACID 在这些事务特性中,数据“一致性”为最终目标,其他特性都是为达到这个目标而采取的措施和手段。数据库...
  • 实现事务原子性,要支持回滚操作,在某个操作失败后,回滚到事务执行之前的状态。 回滚实际上是一个比较高层抽象的概念,大多数DB在实现事务时,是在事务操作的数据快照上进行的(比如,MVCC),并不修改实际的...
  • 事务原子性

    2014-05-15 10:44:39
    事务原子性解析: 例子 A想要从自己的帐户中转1000块钱到B的帐户里。那个从A开始转帐,到转帐结束的这一个过程,称之为一个事务。在这个事务里,要做如下操作: 1. 从A的帐户中减去1000块钱。如果A的帐户原来有...
  • 看到别的博客说,一致性是事务的最终目的,原子性、隔离性、持久性都是为了实现一致性。 在这里,我打算验证一番。 怎么验证呢? 假设,这个事务系统如果是由我们来设计的话。 首先,场景是这样的,小范转100块...
  • 原子性 事务是数据库的逻辑工作单位,事务中包含的各操作要么都做,要么都不做 一致性 事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时,就说数据库...
  • 事务的四种特性中,原子性、一致性、持久性通过数据库的redo log和undo log来完成,redo log称为重做日志,用来保证事务原子性和持久性,undo log称为回滚日志,用来保证事务的一致性。事务的隔离性通过锁机制来...
  • Spring事务一:事务原子性控制以及事务传播特性: 我们学习的AOP,最重要的就是对事务的控制。 实际项目中,对数据库的单次操作,如一次insert,我们在jdbc Template中,使用的是jdbc的事务,会自动的为我们提交...
  • MySQL事务原子性

    千次阅读 2018-08-12 23:17:54
    一、事务的ACID特性: 1)原子性 2)一致性 3)隔离性 4)持久性 二、对于事务原子性(A)我们知道事务中的操...
  • 事务四大特征原子性(Atomicity)一致性(Consistency)隔离性(Isolation)持久性(Durability) 原子性(Atomicity) 原子性是指事务是一个不可分割的工作单位, 事务中的操作要么都执行, 要么都不执行 一致性(Consistency) ...
  • Redis 事务原子性的吗

    千次阅读 2017-06-19 22:44:47
    Redis 事务原子性的吗 转自:http://blog.csdn.net/mindfloating/article/details/8121479/ Redis 提供的事务机制与传统的数据库事务有些不同,传统数据库事务必须维护以下特性:原子性(Atomicity), 一致性...
  • Redis事务是否支持原子性? 因为 Redis 事务不支持事务回滚机制,所以如果事务执行中出现了命令执行错误(例如对 String 类型的key执行 LPUSH 操作),只会返回当前命令执行的错误给客户端,并不会影响下面命令的...
  • 我们既要批量去放入缓存,又要保证每个key都加上过期时间(以防key永不过期),这时候事务操作是个比较好的选择为了确保连续多个操作的原子性,我们常用的数据库都会有事务的支持,Redis也不例外。但它又和关系型...
  • 为什么会出现事务 [1]Transactions are not a law of nature; they were created with a purpose, namely to simplify the programming model for applications accessing a database. By using transactions, the ...
  • 事务原子性

    千次阅读 2016-04-11 13:26:47
    事务原子性指的是,事务中包含的程序作为系统的逻辑工作单位,它所做的对数据修改操作要么全部执行,要么完全不执行。这种特性称为原子性原子性的意义是数据库系统的基础。 也许有的人想大多数程序员都没有...
  • 实现事务原子性,要支持回滚操作,在某个操作失败后,回滚到事务执行之前的状态。 回滚实际上是一个比较高层抽象的概念,大多数DB在实现事务时,是在事务操作的数据快照上进行的(比如,MVCC),并不修改实际的...
  • undo logUndo log 是为了实现事务原子性。还用Undo Log来实现多版本并发控制(简称:MVCC)。事务原子性事务的所有操作,要么全部完成,要不都不做,不能只做一半。如果在执行的过程中发生了错误,要回到事务开始...
  • 事务一致性与原子性的区别

    千次阅读 2017-12-29 14:19:50
    其实一致性和原子性事务里是两个不太相关,但又很相关的逻辑来的 原子性:这个侧重点是事务执行的完整,一套事务下来,如果有一个失败,那整体失败。也就是要么大家一起成功,要么全都回滚 一致性:这个讲的...
  • 原子性:熟悉数据库特性的我们都知道数据库sql执行中也有原子性,数据库中的原子性是这样定义的在一个事务中要么所有的sql都执行,要么都不执行。 java内存模型中的原子性也是类似,要么所有的指令都执行,要么都不...
  • 每执行一个update ,delete或者insert的时候都会自动提交到数据库,无法回滚事务。 设置connection.setAutoCommit(false);只有程序调用connection.commit()的时候才会将先前执行的各语句一起提交到数据库;或者先前...
  • ... 数据库事务  编辑 数据库事务(Database Transaction) ,是指作为单个逻辑工作单元执行的一系列操作,要么完全地执行,要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都...
  • oracle 事务原子性

    千次阅读 2013-08-17 15:54:10
    原子性(atomicity):事务中的所有动作要么都发生,要么都不发生。 一致性(consistency): 事务将数据库从一种一致性状态转变为下一种一致状态。 隔离性(isolation): 事务之间不会相互影响,事务之间是不可见的。...
  • Java运用事务处理(原子性

    千次阅读 2016-11-18 19:15:52
    java的事务处理,如果对数据库进行多次操作,每一次的执行或步骤都是一个事务.如果数据库操作在某一步没有执行或出现异常而导致事务失败,这样有的事务被执行有的就没有被执行,从而就有了事务的回滚,取消先前的操作.......
  • (1) 原子性 事务原子性指的是,事务中包含的程序作为数据库的逻辑工作单位,它所做的对数据修改操作要么全部执行,要么完全不执行。这种特性称为原子性事务原子性要求,如果把一个事务可看作是一个程序,它...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 172,733
精华内容 69,093
关键字:

事务原子性

友情链接: bdoadmintool-master.zip