精华内容
下载资源
问答
  • 关于达梦数据库事务的隔离级别介绍达梦与Oracle支持的隔离级别脏读不可重复读幻读隔离级别的实现读提交隔离级串行化隔离级读未提交隔离级只读事务 达梦与Oracle支持的隔离级别 达梦 Oracle 读未提交 无 读...

    1、 达梦与Oracle支持的隔离级别

    达梦 Oracle
    读未提交
    读提交 读提交
    重复读 重复读
    序列化 序列化

    然后我们再来看SQL-92 定义的四个隔离级别
    在这里插入图片描述
    也就是说Oracle数据库是没有脏读的,达梦和Oracle一样默认的隔离级别都是读提交。
    首先我们先来认识一下脏读、不可重复读、幻读的概念,再来介绍怎么实现这几种隔离级别。

    脏读

    比如说我们开启2个会话,当A会话的事务可以读取到B会话的已修改尚未提交的事务,这个时候就会产生脏读。

    不可重复读

    当A会话的同一个事务、同一个查询,如果是因为其他会话的事务修改过或删除的数据,造成查询的数据不一致。这种现象称为不可重复读。

    幻读

    当A会话的同一个事务、同一个查询,如果是因为其他会话的事务添加的数据,造成查询的数据不一致。这种现象称为幻读。

    2、隔离级别的实现

    读提交隔离级

    数据库的读提交隔离可以确保只访问到已提交事务修改的数据,保证数据处于一致性状态。

    SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
    

    串行化隔离级

    在要求消除不可重复读取或幻像读的情况下,我们可以设置事务隔离级为串行化。跟读提交隔离级相比,串行化事务的查询本身不会增加任何代价,但修改数据可能引发“串行化事务被打断”错误。
    具体来说,当一个串行化事务试图更新或删除数据时,而这些数据在此事务开始后被其他事务修改并提交时,DM 数据库将报“串行化事务被打断”错误。应用开发者应该充分考虑串行化事务带来的回滚及重做事务的开销,从应用逻辑上避免对相同数据行的激烈竞争导致产生大量事务回滚。并结合应用逻辑,捕获“串行化事务被打断”错误,进行事务重做等相应处理。如果系统中存在长时间运行的写事务,并且该长事务所操作的数据还会被其他短事务频繁更新的话,最好避免使用串行化事务。

    SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
    

    读未提交隔离级

    读未提交隔离级别是最不严格的隔离级别。实际上,在使用这个隔离级别时,会发生脏读、不可重复读和幻像。一般来说,读未提交隔离级别通常只用于访问只读表和只读视图,以消除可见性判断带来的系统开销,提升查询性能。

    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
    

    只读事务

    除了前面所述的各种标准特性外,DM 数据库还支持只读事务,只读事务只能访问数据,但不能修改数据。并且只读事务不会改变事务原有的隔离级。

    SET TRANSACTION READ ONLY;
    
    展开全文
  • 先说一下事务的ACID四个特性,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。 其他的几个特性应该很好理解,但是一致性这个概念不太好理解,在这一致性指的数据比较合理,...

        本文主要分析在不牵扯分布式的情况下事务与一致性的实现办法。先说一下事务的ACID四个特性,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。

        其他的几个特性应该很好理解,但是一致性这个概念不太好理解,在这一致性指的是数据比较合理,在经过一系列的操作之后数据依然是我们想要看到的,并不是指的语法上的规则,常见的说明例子就是转账问题。

        redu和undo机制是数据库实现事务的基础。redu日志用来在断电/数据库崩溃等状况发生时重演一次刷数据的过程,把redo日志里的数据刷到数据库里,保证了事务的持久性(Durability);undo日志是在事务执行失败的时候撤销对数据库的操作,保证了事务的原子性(Atomicity)。

        但是只有只有原子性和持久性是无法保证数据一致性的,例如:事务1对A用户加了100元,首先获取A的数据,但是这时事务2也对A加了100元,结果应该是加了200元,但是事务1覆盖了事务2,最后只加了100元,所以需要把两个事务隔离起来,即隔离性(Isolation),使的两个事务并发和串行执行的结果都是一致的。

        数据库使用锁的方式保证隔离性(也就是最终数据保证了一致性),InnoDB实现的方式有以下两种:

    1. 悲观锁控制
    2. 乐观锁(数据多版本)控制

    悲观锁:拿来数据就先上锁,这样别的线程拿数据就会阻塞。像行锁,页锁,表锁以及共享锁,排它锁都是悲观锁。我们说的那些锁一般都是悲观锁。

    乐观锁:悲观锁只是一种概念,其实没有锁,MySql默认其他线程不会改变数据,所以不加锁,只是在提交的时候判断是不是被更改过了,一般用版本戳(MVCC )来实现乐观锁。

    一,使用(悲观)锁控制

    按照锁的使用方式分为共享锁和排它锁。

    共享锁(Share Locks,S锁):一个线程给数据加上共享锁后,其他线程只能读取数据,不能修改。

    排它锁(eXclusive Locks,X锁):一个线程给数据加上排它锁后,其他线程不能读取也不能修改。

    没有锁:InnoDB所有的普通select都是快照读,都不加锁。

    兼容性规则为:共享锁和共享锁兼容,排它锁和其他的锁都排斥。

        如果一个请求的锁模式与当前的锁兼容,InnoDB就将请求授予该事务,反之,如果两者不兼容,该事物就会等到锁释放。

        对于update,delete和insert语句,InnoDB会自动给涉及的数据加排它锁,所以如果插入操作卡住了也无法查询;

        对于普通的select语句,InnoDB不会加任何锁;

    事务也可以通过以下语句手动的给事务加共享锁和排它锁:

        select * from table_name where  ... lock in share mode 会给事务加上共享锁;

        select * from table_name where ... for update 会给事务加上排它锁。

     

    按照锁的粒度分为行锁和表锁以及间隙锁

    行锁是通过给索引上的索引项加锁来实现的,只有通过索引条件来检索数据才会用到行锁,否则InnoDB将会使用表锁。

    表锁:select * from table_nane where name = ‘小巷’  for update 。name字段不是唯一索引字段,所以是表锁。

    行锁:select * from table_name where  id = 1 for update 。id 字段为唯一索引字段,所以使用的就是行锁,且是排它锁。

    页锁(又叫Gap锁):又称为间隙锁。所谓表锁锁表,行锁锁行,那么页锁折中,锁相邻的一组数据,可以用来防止幻读。

    通过加锁控制,可以保证数据的一致性,但是同样一条数据,不论用什么样的锁,只可以并发读,并不可以读写并发(因为写的时候加的是排他锁所以不可以读),这时就要引入数据多版本控制了,也就是乐观锁这个概念。

     

    二,使用数据多版本(MVCC)控制

        使用锁控制并发时,只要是写数据的任务没有完成,数据就不可以被其他的任务获取,就连读数据的select操作也会阻塞,这对并发度要求较大的环境有很大的影响,为了解决这个问题引出了数据多版本。

    数据多版本实现的原理是:

    1,写任务发生时,首先复制一份旧数据,以版本号区分

    2,写任务操作新克隆的数据,直至提交

    3,并发读的任务可以继续从旧数据(快照)读取数据,不至于堵塞

    • 排它锁 是 串行执行
    • 共享锁 是 读读并发
    • 数据多版本 是 读写并发

     

    三,redo,undo,回滚段

    在InnoDB的具体实现上,依赖redo日志,undo日志,回滚段(rollback segment)

    redo日志的作用?

        数据库事务提交后,按照随机方式写入磁盘上性能太低,为了提高效率先写到redo日志里,再刷到磁盘上(此时变成了顺序写)。

    假如我在提交事务时数据库崩溃了,重启时,会从redo日志里把没有刷到磁盘的数据刷到磁盘上(redo意为把刷磁盘的操作进行一次重演)。简言之,redo的作用是为了保障已提交事务的ACID特性,也就是保证了数据的D(Durability)持久性。

    undo日志的作用?

        数据库修改数据但未提交时,会将事务修改数据的镜像(即旧数据)存到undo日志里,当事务回滚或数据库崩溃时,会从undo日志里获取旧数据,避免未提交数据对数据库的影响。简言之,undo的作用是为了保障未提交的事务不会对数据库的ACID产生影响。也就是保证了操作的A(Atomicity)原子性。

    回滚段的作用?

        存储undu日志的地方,就是回滚段。

     

    • InnoDB所有的普通select都是快照读,快照读不加锁。这也是InnoDB支持高并发的一个原因之一

     

     

    参考:

    https://www.zhihu.com/question/30272728

    https://blog.csdn.net/xiangwanpeng/article/details/55106732

    https://blog.csdn.net/tanga842428/article/details/52748531

    展开全文
  • 个令大多数后端同学头疼问题。部分因为不同文章、...本文期望在众多文献中找到一条容易理解知识线,帮助大家在实际工作中更加容易明白到底怎么使用数据库的事务隔离级别和锁。 ACID真实含义 一般都...

    https://www.jianshu.com/p/cb97f76a92fd

    这是个令大多数后端同学头疼的问题。部分是因为不同的文章、文档充斥着不相容的概念。高层抽象和底层实现混到一起令人傻傻的分不清楚。此外还有一部分是SQL标准和实现压根就不一致。本文期望在众多文献中找到一条容易理解知识线,帮助大家在实际工作中更加容易明白到底怎么使用数据库的事务、隔离级别和锁。

    ACID的真实含义

    一般都会用ACID来表达事务的特性。A、C、I、D分别代表“原子性”,“一致性”,“隔离性”和“持久性“。这是1983年(恰好是我出生的年份)ACM的一篇期刊文章Principles of Transaction-Oriented Database Recovery给出的。这四条特性指导了30多年来数据库的模型、设计和开发。ACID很重要,基本上每篇关于数据库的事务的书、文章都要把他们拿出来重新解释一遍。但是,似乎很多人看了很多遍这种文章还是不明白(包括我在内)。因为简单列举,解释这4个概念和现实中数据库的实现不那么容易接起来。

    我是这样理解这几个概念的:

    • Atomicity,原子性。很令人郁闷的是,这个词表达意思与常规语境下不太一样。对于一门支持并发的编程语言(比如Java,C++),原子性是指一组指令被执行时,不受其他指令的干扰。比如我们可以说“CAS是原子的;给一个整型变量赋值是原子的”等等。但是在ACID语境下,“不受干扰”这层意思其实是后边“隔离性“说的事情。在ACID语境下,原子性是指一组对数据库的改变,要么最终成功执行完成,要不就全部回滚。这就要求数据库系统要实现某种回滚的机制,比如redo/undo log)。所以,也许这里用术语”revertability“可能更适合。与事务性数据库相比,一些NoSQL的数据库也声称支持原子性,但是意义不同。比如Redis事务的原子性的意思可能更接近于“一组指令被执行时,不受其他指令的干扰”,而不是“可以回滚”。
    • Consistency, 一致性。这个术语的用词也颇为怪异。一般来讲,我们习惯用“一致性”来描述数据在某些条件下可以变成一样的。例如,在描述CPU工作方式时可以说需要主内存在CPU Core1里的缓存和CPU Core2里的缓存是“一致的“;或者,一个分布式数据系统中,A节点从B节点复制数据,A的数据要和B的数据"严格一致"或者“最终一致”。而ACID下的一致性指的是,在事务完成前后,数据都是要在业务意义上是”正确的“,所以也许术语”correctness“更适合这里的意思。但如果这样定义的话,数据库的位置就很尴尬了,因为保证业务是否正确是要业务代码来最终保证的,数据库能做的非常有限。目前数据库里实现的约束检查,比如唯一约束、外键约束、一些enum测检查、一些数据类型/长度/有效数字的检查等等,对于简单的场景还可以使用。对于复杂的业务约束检查,很难或者不可能实现。有一类数据正确性问题正是由于下面隔离性的使用不当而带来的。 真实复杂业务的数据正确性维护一般用正确的业务代码 + 合法性job来定时执行 + 数据库自身的简单合法性防护一起实现。
    • Isolation,隔离性。是指一组对数据库的并发修改互相不影响。这个概念表面上看来并不是能说得通,因为如果并发修改的是互不相干的数据,那么自然隔离性可以得到满足;如果并发修改的是相关联的,或者就是同一份数据,就必然会相互影响。那么,此时可以做的就是区分哪个修改优先级更加高。而高优先级的修改应该覆盖掉低优先级的修改。但是,现实往往更复杂,因为并发的修改并不一定能够讲明白先来后到的(要不怎么叫并发呢),此时谁应该生效无法很好的定义。另外一种情况是“先读取,再基于读取结果对数据进行修改”这样业务逻辑。比如,先找到可用的库存,有则扣减,没有则提示缺货;再比如先读取当前的计数值,再往上加1。这时保证隔离性的主要问题不在于隔离本身,而在于如果将读取作为对数据修改的前提条件,之后在对数据进行修改的一刹那,读取时的前提条件还是否满足。毕竟读取和写入是两个分开的指令,而在这两个指令中间可能夹杂其他事务对数据的修改。保持隔离性的一个简单做法是保证对关联数据的修改串行化,对应事务性数据库的“Serializable”隔离级别。保证串行化的一种方案是,通过锁定可以彻底避免竞争条件。但是大家都能明白加锁对数据库并发的性能负面影响很大,所以就衍生出了几种弱一些的隔离性保证——READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ。此外MVCC能够解决一部分锁带来的问题。这些内容在下文中会详细的讲解。
    • Duration,持久性。是指对数据的修改,一旦完成,该结果就应当永远不丢失。这是这4个术语中我唯一觉得表面上和实际上意思差不多的一条。在现实当中,一般通过持久性存储设备(比如磁盘/SSD)写入并刷新来保证数据的持久性。如果觉得一个节点不靠谱,可以增加多个副本(replica)一起来保证持久;如果觉得这样还不够靠谱,可以在不同的地理位置的另一个数据中心做备份。实际上绝对的持久性是不存在的,因为整个存储层面有很多不确定因素,比如文件系统本身fsync指令实现有bug,磁盘的固件有bug,供电出现问题造成数据错乱,异步的数据复制没有生效等等。所以在现实当中的数据库,只能在当前成本和技术限制的约束下,尽量维持一定程度的持久性。

    所以这么整理起来。实际上事务性数据库实现的是

    • 支持未完成的数据修改回滚的机制,对应“原子性”
    • 力所能及的数据合法性检查,对应“一致性”
    • 保证数据并发的修改的规则,对应“隔离性”
    • 使用基于持久化存储(磁盘、SSD)的方式对数据进行存储,对应“持久性”

    这四条中一、二、四不是本文要讨论的内容,不再赘述。后面主要来谈一下第三条——隔离性规则,即隔离级别的实现。

    隔离级别和并发控制

    SQL92标准定义了四种隔离级别——Read Uncommitted,Read Committed,Repeatable Read和Serializable。定义这4种隔离级别时,制定者主要围绕着基于锁的并发控制来说的。但是后来出现了MVCC,之后主流数据库都开始支持MVCC。有的数据库采用比较纯粹的MVCC实现,比如PostgreSQL;有的则是混杂的,比如MySQL InnoDB。这就会造成数据库的实现和标准的描述有很多出入。

    其实我们并不在意标准怎么说。标准只是一个参考,引导我们理解我们能够接触的实际数据库系统的工作原理。我们先从最简单情况谈起。

    最不严格的隔离级别

    理论上,最不严格的隔离级别应该是不隔离。

    不隔离很容易理解,不同的事务可以对同一数据并发的随便改:A事务改了一半的结果B能看到;B改了一半的结果A也能看到;如果A和B反复修改同一个数据,那么彼此的修改可以覆盖。数据系统在没有做隔离防护时,就一定会是这个样子。这样也就无所谓事务了。

    这里数据访问冲突可以分为两种:

    • Dirty Read,脏读。即一个事务的没提交之前的修改被另外一个事务可以看到。
    • Dirty Write,脏写。即一个事务的没提交之前的修改可以被另外一个事务的修改覆盖掉。

    其实脏读在某些场景下还是可以接受的,比如完全不需要“读取-计算-修改”逻辑的事务。这种事务完全不在意别的事物是怎么修改的,就是自己改自己的;要不就是业务上“就算是基于一个错误的前提进行了数据修改,结果也可以接受”的场景。

    而脏写是无法被接受的,因为他会让事务原子性无法实现。试想以下A和B两个事务的行为(假设x的值一开始是0):

    事务A 事务B
    set x = 1  
      set x = 2
    get x (得到2)  
      rollback
    commit  

    事务B将事务A的修改覆盖了,将x改为2,然后回滚。但是事务A却commit了。此时x应该是多少呢?从事务A的角度可能应该是1,但是从事务B的角度应该是0。这种情况无论如何都不能自洽。因此,任何支持事务的数据库都有一个基本原则:不论隔离级别是什么,脏写都是不允许的!!

    如何避免脏写呢?答案很简单——使用锁。实际上,一般数据库都会使用排他锁来标记要修改的数据(update,delete,select … for update)。锁的存在可以保证——写要block写。这个规则永远生效。

    在MySQL InnoDB中,这种锁被称为“X锁”。它的特性是,只要有一个事务获取了一条数据的X锁,其他事物如果也想获取这个锁,就必须等待,直到第一个事务提交/回滚后释放锁,或者等到超时自动回滚。例如上面的例子的第二行事务B尝试进行set x = 2就会被排他锁卡住。有很多教程会提示一些数据库的某些隔离级别是使用MVCC而不是锁的方案来实现的,说的好像用了MVCC就完全不需要锁。这是非常容易引起误解的。事务数据库对于写操作永远需要锁来避免脏写,即使是基于MVCC的数据库。所谓某个隔离级别使用MVCC不需要锁,仅仅是指在读取的时候是否需要锁。

    所以,最不严格的隔离级别的隔离级别是允许脏读,但不允许脏写。这种隔离级别被称为Read Uncommitted。这种隔离级别一般不建议使用。事务应该是数据被修改的最小单位,而Read Uncommitted丧失了“事务”这个词本身存在的意义。虽然该隔离级别可以带来一些性能上的优势,但因为其容易造成数据由于并发操作带来的问题,所以应该用在不不太在意数据正确性的场景。但如果你的业务需要性能上的优势,就说明请求量很高,而请求量很高的业务一般很重要,不太可能不需要数据正确性。如果访问请求量不高,直接用默认的隔离级别(有的数据库是Read Committed,有的是Repeatable Read)就是了,没有必要去折腾数据库配置。

    如果是高性能的简单数据操作(比如根据数据ID直接修改数据行),用Read Uncommitted是可行的。但既然这样,为什么不用一个正儿八经的NoSQL数据库(比如RocksDB),从而得到高的多写入性能?

    Read Uncommitted在SQL92里被定义为最低级别的隔离。但在PostgreSQL中,Read Uncommitted压根就没有实现,设置Read Uncommitted等价于设置Read Committed。

    简单来说,对于事务性数据库,Read Uncommitted是鸡肋一般的存在。诸位可以无视之。

    Read Committed和Repeatable Read

    把这俩种隔离级别放一起说是因为它们的基本原则是一样的:读不block读和写,写不block读。只不过是发生了并行读写的隔离效果不太一样。此外,它们两个对OLTP业务代码的编写的影响差不多——它们都无法解决“写前提困境“。在深入讨论之前,这里先复述一遍这俩隔离级别的意思。

    Read Committed是指一个事务能看到另外一个事务对一条数据记录已经提交的修改。例如下面的操作序列(假设变量x的值一开始是0):

    事务A 事务B
    get x (得到0)  
      set x = 1
      commit
    get x (得到1)  
    commit  

    这里可以看到事务A对x的两次读取,因为发生在事务B对x修改的前后,得到了不同的结果。事务A可以看到事务B已经提交的修改。

    Repeatable Read是指一个事务一旦开始,反复读取一条数据记录,都会得到相同的结果。或者说,假如有两个事务A和B,A在B之前开始,那么B对数据的修改对于事务A总是不可见的。例如下面的操作序列(假设变量x的值一开始是0):

    事务A 事务B
    get x (得到0)  
      set x = 1
      commit
    get x (得到0)  
    commit  

    Repeatable Read的直观感觉仿佛是给事务做一个整个数据库做了一个快照,所以很多时候这种隔离级别又被称为Snapshot Isolation。"快照"的功能在一些场景下非常重要,如:

    • 数据备份。例如数据库S从数据库M中复制数据,但是同时M数据库又被持续修改。S需要拿到一个M的数据快照,但是又不能真的把M给停了。
    • 数据合法性检查。例如有两张数据表,一张记录了当时的交易总额,另外一张表记录了每个交易的金额。那么在读取数据时,如果没有快照的存在,交易金额的总和可能与当时的交易总额对不上,因为随着检查事务的进行,新的交易记录数据会被提交。这些新的提交会被检查事务看到。

    在基于MVCC的数据库中,一般认为只实现了Read Committed和Repeatable Read两隔离级别。PostgreSQL在9.1以前,Serializable和Repeatable Read是一样的(PostgreSQL 9.1以后的Serializable增强了数据依赖性的检查)。

    此外值得一提的是幻读的问题。在SQL92标准中提到了Repeatable Read中是可以出现幻读的——即一个事务尽管不能读取到后续其他事务对现有数据的修改,但是能够读取到插入的新数据。但是,基于MVCC的实现,Repeatable Read可以完全避免幻读(这岂不是更好)。无论MySQL还是PostgreSQL在Repeatable Read隔离级别都不会出现幻读。

    MVCC

    MVCC是"Multi-Version Concurrency Control"的缩写。名字看上去很吓唬人,有点不明觉厉,但是可以这样简单理解——对数据库的任何修改的提交都不会直接覆盖之前的数据,而是产生一个新的版本与老版本共存,使得读取时可以完全不加锁。这个版本一般用进行数据操作的事务ID(单调递增)来定义。MVCC大致可以这么实现:

    每个数据记录携带两个额外的数据created_by_txn_iddeleted_by_txn_id

    • 当一个数据被insert时,created_by_txn_id记录下插入该数据的事务ID,deleted_by_txn_id留空。
    • 当一个数据被delete时,该数据的deleted_by_txn_id记录执行该删除的事务ID。
    • 当一个数据被update时,原有数据的deleted_by_txn_id记录执行该更新的事务ID,并且新增一条新的数据记录,其created_by_txn_id记录下更新该数据的事务ID

    在另一个事务进行读取时,由隔离级别来控制到底取哪个版本。同时,在读取过程中,完全不加锁(除非用SELECT … FOR UPDATE强行加锁)。这样可以极大降低数据读取时因为冲突被Block的机会。

    那么那些多出来的无用数据怎么被最终被清理呢?支持MVCC的数据库一般会有一个背景任务来定时清理那些肯定没用的数据。只要一个数据记录的deleted_by_txn_id不为空,并且比当前还没结束的事务ID中最小的一个还要小,该数据记录就可以被清理掉。在PostgreSQL中,这个背景任务叫做“VACUUM”进程;而在MySQL InnoDB中,叫做“purge“。

    在PostgreSQL的实现中,MVCC产生的所有版本的节点都生成存储数据表的B+树的节点。新的节点和老的节点并存,只是上边的标记不同。这个实现的好处是选择读取哪个版本非常方便,可以和B+树的搜索算法合并到一起,还能兼顾SSI检测(下文会提到)。坏处是清理废弃数据相对麻烦。

    MySQL采用Undo Log的实现。这种实现下,用于存储数据表的B+树节点总是只保留最新的数据,而老版本的数据被放在Undo Log里,并且以指针的形式关联起来,形成一个链表。这样,在查找老的版本时,需要按链表顺序查找,直到找到created_by_txn_id <= 当前事务ID的最新那条记录即可。这种实现的优缺点和PostgreSQL正相反,查询时会在B+树查找后多引入一个链表查询;但是清理废弃数据时会更简单,只要把Undo Log找到一个合适的位置一刀切了即可。

    有了MVCC,Read Committed和Repeatable Read就的实现就很直观了:

    • 对于Read Committed,每次读取时,总是取最新的,被提交的那个版本的数据记录。
    • 对于Repeatable Read,每次读取时,总是取created_by_txn_id小于等于当前事务ID的那些数据记录。在这个范围内,如果某一数据多个版本都存在,则取最新的。

    有趣的是,隔离级别可以是一个Session级别的配置。即每一个Session可以在运行时选择自己希望使用什么隔离级别,也可以随时修改(只要当前没有尚未结束的事务)。每个Session的隔离级别和其他Session是什么隔离级别完全无关。Session只要根据自己的隔离级别,选择用MVCC提供的合适的版本即可。

    MySQL InnoDB、PostgreSQL、Oracle (从版本4开始)、MS SQL Server(从版本2005开始)都实现了MVCC。值得一提的是MySQL InnoDB尽管一开始就实现了MVCC,但是之前很多人还在使用MyISAM存储引擎,而MyISAM根本就不支持事务,更不要提MVCC。直到MySQL 5.5.5,InnoDB才成为MySQL默认的搜索引擎。因此如果有想用MySQL做隔离级别实验的读者最好先弄清自己用的MySQL版本和存储引擎。

    写前提困境

    尽管在MVCC的加持下Read Committed和Repeatable Read都可以得到很好的实现。但是对于某些业务代码来讲,在当前事务中看到/看不到其他的事务已经提交的修改的意义不是很大。这种业务代码一般是这样的:

    1. 先读取一段现有的数据
    2. 在这个数据的基础上做逻辑判断或者计算;
    3. 将计算的结果写回数据库。

    这样第三步的写入就会依赖第一步的读取。但是在1和3之间,不管业务代码离得有多近,都无法避免其他事务的并发修改。换句话说,步骤1的数据正确是步骤3能够在业务上正确的前提

    在Repeatable Read下是解决不了这个问题的,因为在步骤3时,当前事务根本就无法看到另外一个事务对数据的修改。这个问题一般被称为Lost Updates。看这个例子,假设用Repeatable Read隔离级别实现一个计数器:

    事务A 事务B
    get counter (counter = 1)  
      get counter (counter = 1)
      counter = counter + 1 (counter = 2)
      set counter = 2
      commit
    counter = counter + 1 (counter = 2)  
    set counter = 2  
    commit  

    这时,事务A结束后,就会丢掉一次counter的计数。

    而Read Commited尽管能够看到其他事务已经提交的修改,问题在于,在Read Commited,你必须重复写一句select语句才能拿到。而不管你反复读取多少次,不管这个select离得与下面的update有多近,理论上都无法避免丢失其他事务的修改。

    简单来说,这个问题就是在修改的事务在提交时,无法确保这个修改的前提是否还可靠。这种问题我称之为写前提困境

    解决这类问题有3种办法:

    • 数据库支持某种代码块,这个代码块的执行是排他的;
    • 加悲观锁,把期望依赖的数据独占,在修改完成前不允许其他并发修改发生;
    • 加乐观锁,在事务提交的一刹那(注意是commit时,不是修改时),检查修改的依赖是不是没有被修改;

    在事务性数据库中,第一种被称为Actual Serial Execution,第二种是加锁(手工或者自动);第三种被称为Serializable Snapshot Isolation, SSI

    Actual Serial Execution

    Actual Serial Execution是一种执行的效果,即一段代码在数据库服务器端执行时不会受到其他并发控制的干扰。但要达成这个效果并不简单。

    最简单的实现方案是让整个数据库只能单线程跑。这样什么并发隔离保护的机制都可以不要,所有的数据不会有任何并发修改的问题。一些NoSQL的存储,如Redis、VoltDB都是这么实现的。但是他们这么实现是有原因的,因为他们都是基于内存的存储,其数据操作的延迟相对于网络IO几乎可以忽略不计。所以即使是单线程,配合nonblocking IO,他们的并发性能也可以非常高。但这个假设对事务性数据库并不成立,因为事务性数据库要操作磁盘/SSD。即便是SSD的写入速度,也会在数量级上低于内存。所以事务性数据库如果强行改成单线程,就会极大的损害并发性能。

    此外,单线程存储因为只能使用单线程,所以一个实例只能使用一个CPU核心。在多核心机器上就会浪费资源。所以往往要单机启用多个实例。而一旦启用多个实例就意味着要提前对数据进行Partition,分配给多个实例。但是Partition会造成单Partion查询方便,跨越多个Partition的查询麻烦的问题。所以简单的说,这条路子可以走,但是有比较大的局限性,比较适合为特定业务做定制存储。

    另外一种办法是用存储过程将业务逻辑包起来丢给数据库执行。但这样做其实不现实,因为存储过程本身并不具备原子性和隔离性。为了让存储过程中执行是排他的,依然需要在存储过程里声明一个事务。如果必要,可以声明当前的事务隔离级别为Serializable以避免写前提困境。例如Mysql InnoDB可以这样写。

    CREATE PROCEDURE foo_proc(  
    IN param_1 INT,  
    IN param_2 VARCHAR(100)  
    )  
    BEGIN
      SET TRANSACTION ISOLATION_LEVEL SERIALIZABLE; -- 可以设定下一个事务用Serializable隔离级别
      START TRANSACTION;
      -- 一系列操作代码……
      COMMIT;
    END;  
    

    这种做法其实等价于下面要讲的Serializable隔离级别。

    顺便提一下,存储过程存在一系列使用上的问题,如不好开发,不好调试,不好版本管理,一旦写错可能会拖垮整个数据库服务器等。所以真的用起来先要仔细权衡是否值得使用它。

    最后还有一个招数是用单SQL语句的事务。比如上面的计数器可以这样写:

    UPDATE counter_tbl SET counter = counter + 1 where id = xxx;
    

    这样写的确能保证排他性执行,因为这条语句自身可以成为一个事务,并且因为是UPDATE语句,所以必然会抢占X锁。锁的存在可以确保不会出现写前提困境。但这么做的前提是有办法把一个业务逻辑用一句修改类SQL表达。一个计数器的逻辑可以,但是复杂一些的业务就不行;或者在语法层面可行,但是写出来几百行的SQL,根本无法调试和维护。

    加锁和基于锁的Serializable

    通过加锁可以有效的排除所有可能的竞争问题。在MySQL InnoDB中,Serializable隔离级别是依靠MVCC + 加更多的锁。以下摘自MySQL的文档

    • SERIALIZABLE

    This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... LOCK IN SHARE MODE if autocommit is disabled.

    简单来讲就是所有的读取要加上共享锁。与MySQL不同,在PostgreSQL中,Serializable使用SSI实现,见下文的SSI的介绍。

    数据库中经典的加锁的过程被称为两阶段加锁 (2 Phases Locking, 2PL)。注意这个词和两阶段提交(2PC)很像,但他们是截然不同的两个意思。所谓两阶段加锁是指:

    • 加锁阶段:在事务过程中,根据不同的SQL指令加锁。
    • 释放锁阶段:锁定直到这个事务被提交或者回滚(包括等待超时造成回滚)时释放。

    基于锁的Serializable的实现准则是:读要block写,写也要block读,读不block读

    还是考虑上面计数器的例子,在MySQL InnoDB Serializable隔离级别下的过程。

    事务A 事务B
    get counter (counter = 1, 获取共享锁)  
    counter = counter + 1 (counter = 2)  
    set counter = 2 (获取排他锁,成功)  
      get counter (counter = 1,获取共享锁,会被锁住)
    commit(释放所有事务A的锁) get counter返回,得到counter = 2; 同时获得了counter的共享锁。
      counter = counter + 1 (counter = 3)
      set counter = 3 (获取排他锁)
      commit

    上面的例子解释了counter这条记录上的锁如何避免了counter的竞争问题。

    实际上MySQL的Serializable除了锁记录,还会锁记录的间隙,避免意外的插入。这种锁概念上被称为区间锁(Range Lock)。MySQL InnoDB中的叫法是Gap Lock和Next-key Lock。

    上文中有提到基于MVCC的Repeatable Read可以避免幻读。在基于锁的Serializable中做的更强硬,它会直接锁定以避免插入。

    考虑下面的例子:

    事务A 事务B
    SELECT * FROM user WHERE age >= 20 and age <= 30; (获取区间锁)  
      INSERT INTO user(id, name, age) VALUES(200, 'Jonh', 28); 被区间锁锁住
    commit (释放掉锁) INSERT获取锁定,并成功插入
      commit

    在MySQL中,不同的隔离级别内部实现使用不同的MVCC读取策略+不同种类的锁来完成。这就好像你春节在饭馆吃饭,得点套餐一样。那么如果这些隔离级别没有一个满足心意,或者希望根据业务逻辑实现一些定制优化,是不是可以不可以DIY一下呢?是可以的:

    SELECT ... LOCK IN SHARE MODE -- 尝试将查询符合条件的记录加上共享锁,如果锁已经被占了就等待
    SELECT ... FOR UPDATE -- 尝试将符合查询条件的记录加上与等价UPDATE语句一样的锁,包括排他锁和区间锁
    

    这些语句可以无视当前的隔离级别,完全按照你的心意来加锁。举个例子,假设有一个user数据表有id和name两列。id=3的name数据初始为"tom"。事务A和B都使用隔离级别Repeatable Read。

    事务A 事务B
    select name from user where id = 3; (得到"tom")  
      update user set name = 'jack' where id = 3;
    select name from user where id = 3; (得到“tom", 因为Repeatable Read的缘故)  
    select name from user where id = 3 for update; (会锁住,因为事务B已经获取了锁)  
    在MySQL中,上一句返回,并且会看到'jack'! commit;

    在MySQL中SELECT … FOR UPDATE会打破当前的Repeatable Read隔离级别,拿到另外一个事务提交的最新的数据;同样的行为在PostgreSQL执行的结果不同,PostgreSQL会检测出并发的数据修改而直接回滚事务。

    基于锁的Serializable隔离级别,或者手工加锁,是可以根除任何并发冲突的,但是这是有代价的——大大的增加了锁的数量,同时也就增加了等待锁的时间以及死锁的机会。下面我们再看看SSI。

    SSI和基于SSI实现的Serializable

    相对于悲观锁的方案,相对应的乐观锁的方式就是SSI——Serialized Snopshot Isolation。它的大致意思是:本质上,整个事务还是Snapshot Isolation,但事务在进行过程中,除了对数据进行操作外,还要对整个事务的“写前提”——所有修改操作的依赖数据做追踪。当事务被commit时,当前事务会检查这个“写前提”是否被其他事务修改过,如果是,则回滚掉当前事务。PostgreSQL的Serializable基于SSI实现。

    例如下面的是一个SSI隔离级别的例子。

    事务A 事务B
    get x (得到0)  
      set x = 1
    get x (得到0) commit
    set x = x + 3  
    commit (会失败,因为侦测到另外一个事务已经提交过修改后的x)  

    那么问题在于如何侦测到这个修改已经发生了?基本的办法有:

    • 在一个事务进行提交时,对于所有修改的数据,查看MVCC中是否已经有其他的版本已经提交了但是本事务因为snapshot机制没有读取到
    • 事务进行时,标记自身所有读取过的记录(就好像加共享锁,但是并不真的锁定什么)。另外一个事务如果提交了一个写操作,则反查这个写操作影响到的数据有哪些被读取中,并且读取他们的事务还没提交

    SSI并非绝对优于锁的方案。悲观锁方案和乐观锁方案的权衡点在于,冲突是否足够多。如果冲突太多,SSI会造成大量的资源浪费(做了很多计算,但是就是commit不了);如果冲突不是很多,加锁方案带来锁等待和死锁的负面效果更显著。所以在选取方案之前,先对业务造成的并发修改冲突量有一个估计。

    MySQL和PostgreSQL对比

    通篇看下来你会发现MySQL和PostgreSQL对于并发控制的路子不太一样。这里稍微总结一下:

    隔离级别 MySQL PostgreSQL
    Read Uncommitted 支持 不支持,等价于Read Committed
    Read Committed 支持,基于MVCC实现 支持,基于MVCC实现
    Repeatable Read 支持,基于MVCC实现了Snapshot Isolation,可避免幻读 支持,基于MVCC实现了Snapshot Isolation,可避免幻读
    Serializable 支持,Repeatable Read + 共享锁 支持,基于MVCC实现了Serialized Snapshot Isolation
    默认级别 Repeatable Read Read Committed
    MVCC实现 基于Undo Log 基于B+树直接记录多个版本

    在MySQL中,很多开发者倾向于自己在默认隔离级别之外手工加锁。而PostgreSQL则建议尽量避免直接加锁,因为其Repeatable Read和Serializable的实现已经相当完善,开发者没必要自找麻烦。

    如何写代码

    说了这么多,其实还是要把关注点收回来——在基于事务性数据库进行业务开发时,应该如何进行开发。比如

    • 该选择什么隔离级别?
    • 该怎么加锁?
    • 死锁了怎么办?
    • ……

    我这里给出我的一般性开发原则。

    大部分时候不要操这份心

    因为很多互联网业务其实不需要特别在意并发时的正确性。比如一个社交网站大家发博客。一个用户自己管理自己的博客,几乎不太可能出并发性的问题。考虑如下的schema:

    create table blog (
        blog_id int primary key auto_increment,
        author_id int not null,
        title varchar(40) not null,
        content longtext not null default ''
        created_at datetime default current_timestamp,
        updated_at datetime default current_timestamp on update current_timestam,
    );
    

    如果发生了并发的问题,就意味着用户同时在多个设备上编辑自己的博客,并几乎同时点击“保存”。这在现实中发生的几率非常少。即便发生了,数据会以稍后commit的事务为准。在业务上这种级别的正确性完全是可以接受的。本质上,这种场景天然的让数据发生了partition(本例子中author_id可以作为partition key),不同的事务只是修改自己那份partition而已,不会相互影响。

    所以此时只需要使用数据库默认的隔离级别就可以了。基于MVCC的实现基本上免除了大部分的锁等待问题。

    为特定的业务场景做优化

    那么什么时候会遇到并发修改问题?比如:

    有全局数据需要增减。例如的库存数量/垫资额度要扣减。此时应该选择Serializable隔离级别或者手工SELECT … FOR UPDATE加锁。但是要特别留意,因为这样做会增加死锁等待/并发修改造成事务失败的问题发生的几率,所以尽量保证事务的粒度尽可能的小。避免一个巨大的事务长时间执行。

    20~30年前对数据改动的业务逻辑的主流实现方法是,将全部业务逻辑实现在一个巨大的存储过程里,然后配合适当的隔离级别。现在的基于Web/App的业务流程早已转变成以交互为核心,所以业务逻辑会被拆解到若干个细小的事务里。其中一些业务流程(如第三方支付)不可避免的必须从事务中分离出来,做成分布式的事务。

    需要读取大量数据。例如业务清算时需要读取一段时间所有的交易记录和资金流水。这种场景不属于OLTP,应该选择Repeatable Read隔离级别得到一个“快照”,并标记事务为只读SET TRANSACTION READ ONLY。这样会让数据库对事务的执行做优化,尽量避免冲突的发生。

    海量数据插入到OLTP数据库。比如交易系统把每天用户的资产和收益计算后更新到OLTP数据库让用户访问。此时应该实现一个“业务事务”的概念。即不要依靠数据库的业务,而是依靠一个标记。当一个用户的数据正在更新时,应该避免用户看到部分被更新的数据。只有当数据全部更新完了,最后更新一下标记,让数据对用户可见。同时,对数据的更新应该拆解一个个小的事务,避免一个巨大的事务一次性完成更新。

    简单的数据读取-更新场景。比如计数器。可以用单行UPDATE SQL的方式实现。前文中有提到。

    特种业务的并发修改。比如共享文档编辑。这种情况下,无法只依靠数据库的并发控制,还必须引入业务级别的冲突检测,自动和手动的Resolve Conflict流程。这类问题找一个专题可以专门讨论一下。

    避免纠结于Repeatable Read和Read Committed的区别

    上文已经提到了,这两个隔离级别都无法解决“写前提困境”。所以除非你是做数据库并发控制的开发者,或者是作为兴趣研究,不要去纠结于这些细节,也不要根据这些细节来有针对性的编写业务代码。业务的发展是完全不可控的,也许今天Read Committed可以,下次稍微改动一点点代码就必须要Repeatable Read。在常规开发中,因为一点点细节的改动就要造成整个并发控制方法发生更改,是需要尽量避免的情况。

    对并发冲突或者死锁尝试进行重试

    在基于锁的实现中,可能会出现锁等待超时回滚;而在基于SSI的实现中,事务提交时可能会检测到并发修改,进而强行回滚事务。无论哪一种,都需要重试。需要编写代码来处理这种重试,并且需要根据业务需求确定重试的驱动者是谁——到底是后端代码,前端代码还是用户需要介入重试。

    对于MySQL考虑乐观锁

    因为MySQL的隔离级别不支持SSI,所以可以考虑手工实现乐观锁。即自己在数据表里增加一个version列,并且在更新数据总是将修改之前的version放在UPDATE语句的where条件里。关于手工实现乐观锁的文章有很多,有些工具比如RoR可以半自动的产生乐观锁代码,这里就不赘述了。

    但是很可惜,乐观锁的实现是有前提的,即修改的数据和修改的前提是同一份数据。如果这个前提不满足就无法实现。比如这个例子: 一组值班的客服可以打卡下班,但是要保证至少有5个客服在岗。假设有一个客服工作状态的表。

    create table supportor_work_status (
        supportor_id int primary key
        active bit not null default b'0'
    );
    

    需要始终这种表里active为1的行数必须高于5个。那么可能的代码为

    int activeCnt = db.query("select count(*) as cnt from supportor_work_status where active = 1");
    if (activeCnt > 5) {
        db.execute("update supportor_work_status set active = 0 where supportor_id = ?, selfId);
    }
    

    该事务在Repeatable Read下有机会造成少于5个人在岗。

    此时,可以考虑“物化冲突”(Materialize Conflict)。即把这个冲突点变成一行数据,让数据库可以根据这行数据检测到冲突。比如上面的例子中,可以增加一个表supportor_active_count记录当前的在岗人数。并且对这条记录增加乐观锁即可。

    注意监控数据库的事务执行情况

    一般监控都能做到监控数据库的CPU、磁盘、IO等资源的占用情况。除此之外,应当注意对事务的执行时间和数量做监控。数据库系统本身一般并不限制事务的执行时间(但是限制事务等待一个锁的时间)。一个执行数小时甚至数天的事务极大概率是有问题的,会带来如死锁增加,MVCC垃圾得不到清理等问题。



    作者:大宽宽
    链接:https://www.jianshu.com/p/cb97f76a92fd
    来源:简书
    简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

    展开全文
  • 事务隔离是基于锁实现的 在DBMS中,可以按照锁的粒度把数据库锁分为行级锁、表级锁和页级锁 行级锁:是mysql中锁定粒度最小的一种锁,表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁...

    事务隔离是基于锁实现

    在DBMS中,可以按照锁的粒度把数据库锁分为行级锁、表级锁和页级锁

    行级锁:是mysql中锁定粒度最小的一种锁,表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小,但开锁的开销也最大。行级锁分为共享锁和排它锁。

    特点:开销大、加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。

    表级锁:是mysql中锁定粒度最大的一种锁,表示对当前操作的整张表加锁,他实现简单,资源消耗少,被大部分mysql引擎支持。最常使用的MYISAM和INNODB都支持表级锁定。表级锁定分为表共享读锁和表独占写锁。

    特点:开销小、加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。

    页级锁:是mysql中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快,但冲突多,行级冲突少,但速度慢。所以取了折中的页级,一次锁定相邻的一组操作。

    特点:开销和加锁时间介于表锁和行锁之间;会出现死锁;锁的粒度介于表级锁和行级锁之间,并发度一般。

    展开全文
  • 事务并发可能产生问题:(在不考虑事务隔离的情况下)脏读:脏读指在一个事务处理过程里读取了另一个未提交的事务数据。不可重复读:不可重复读指在对于数据库某个数据,一个事务范围内多次查询却返回了...
  • 前言说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的清楚事务的这些特性又是怎么实现的,为什么要有四...
  • https://segmentfault.com/a/1190000025156465前言说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的...
  • 水稻: ACID我知道啊,但是不太懂他的实现,你能说和我聊聊事务数据库底层是怎么实现的吗?菜瓜:据我了解,不同的特性底层的实现不一样,主要依赖两种日志和锁来实现先说持久性:我们知道数据的操作会先在内存中...
  • 前言之前的文章mysql锁机制详解中我们详细讲解了innodb的锁机制,锁机制用来保证在并发情况下数据的准确性,而要保证数据准确通常需要事务的支持,而mysql存储引擎innodb通过锁机制来巧妙地实现事务的隔离特性中...
  • mysql中可以用下面的方式自定义隔离级别,** 那么不同的隔离级别的事务之间如何协作处理的数据的呢 ** ?一个事务可以脏读,另一个不允许,怎么处理冲突? 数据库隔离级别我明白的,回答不必扯基本概念,多谢。...
  • 前言说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的清楚事务的这些特性又是怎么实现的,为什么要有四...
  • 这里就来讲讲InnoDB引擎中隔离性是怎么实现的。 READ COMMITED 和 REPEATABLE READ 的隔离性实现:MVCC MVCC即多版本控制系统,为了实现更好的并发,可以使得大部分的读操作不用加锁, 但是insert,delete,update是...
  • 前言说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的清楚事务的这些特性又是怎么实现的,为什么要有四...
  • 前言说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的清楚事务的这些特性又是怎么实现的,为什么要有四...
  • 事务的隔离级别MySQL 是怎么实现事务机制的?MVCC 机制总结为什么需要锁?相信大家都比较熟悉电商系统中库存管理的场景,对于日常活动促销、618、双 11 等场景,会在规定时间内对商品进行促销活动,假设现在有一款 ...
  • 事务隔离隔离性与隔离级别当数据库上有多个事务同时执行时候,就可能出现脏读(dirty read)、不可重复读 (non-repeatable read)、幻读(phantom read)问题,为了解决这些问题,就有 了“隔离级别”概念在谈隔离...
  • 今天想跟大家一起研究下事务内部到底是怎么实现的,在讲解前我想先抛出个问题:事务想要做到什么效果?按我理解,无非是要做到可靠性以及并发处理。可靠性:数据库要保证当insert或update操作时抛异...
  • 说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的清楚事务的这些特性又是怎么实现的,为什么要有四个...
  • 昨晚和以为前辈聊天,聊到Mysql的引擎innodb默认的...那么,问题来了,在Mysql中的隔离级别是怎么实现的呢? 关于数据库数据隔离级别在之前的博客中总结过:https://blog.csdn.net/qq_34417408/article/details/79...
  • 数据库隔离级别及实现原理

    万次阅读 多人点赞 2018-09-15 15:25:27
    面试官让我说说数据库的隔离级别,以及他们各自对应着什么问题,这个还好说,说出来后他接着追问readcommited的原理,当时楞了一下,因为的确没接触过,虽然知道肯定锁的作用,但不知道怎么说好,怎么着手,就直接...
  • 面试官:MySQL事务是怎么实现的

    万次阅读 多人点赞 2020-03-10 23:03:17
    数据库事务通常包含了一个序列对数据库读/写操作。包含有以下两个目的: 为数据库操作序列提供了一个从失败中恢复到正常状态方法,同时提供了数据库即使在异常状态下仍能保持一致性方法。 当多个应用程序在...
  • 前言说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的清楚事务的这些特性又是怎么实现的,为什么要有四...
  • 数据库的事务

    2018-08-24 14:39:53
    问题: 数据库的事务,四个性质说一下,分别有什么用,怎么实现的 一、数据库的事务性质 1、原子性(Atomicity): 事务的原子性指的,事务中包含的程序作为数据库的逻辑工作单位,它所做的对数据修改操作要么...
  • 有待思考和探索,mysql的隔离级别怎样实现的?   以及一般数据库的隔离级别的实现方法?   由此发散,数据库一般事务中的回滚,提交底层实现的机制。 ...
  • 数据库事务

    2020-03-20 22:47:29
    隔离级别和并发问题是什么关系,底层是怎么实现…带着这些问题,让我们开始学习事务吧 2 为什么要有事务 现实中存在很多一组操作需要顺序完成场景,比如转账至少包括A账户减少和B账户增加两步操作,我们希望他们能...
  • 前言说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的清楚事务的这些特性又是怎么实现的,为什么要有...
  • Mysql的innodb存储引擎通过事务来保证数据的一致性的 数据库事务通常包含了一个序列的对数据库的读/写操作包含有以下两个目的 为数据库操作序列提供了一个从失败中恢复到...事务的特性有原子性,隔离性,持久...
  • 前言说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的清楚事务的这些特性又是怎么实现的,为什么要有...
  • 公众号:「古时风筝」,更多干货。经常提到数据库事务,那你知道数据库还有事务...数据库事务的是一组数据操作,事务内操作要么就是全部成功,要么就是全部失败,什么都不做,其实不是没做,可能做了一...

空空如也

空空如也

1 2 3 4 5 ... 15
收藏数 296
精华内容 118
关键字:

数据库事务的隔离是怎么实现的