数据库之事物隔离级别
数据库的四大特性以及四个隔离级别和引发的问题
数据库的四⼤特性以及四个隔离级别和引发的问题四⼤特性（ACID）1.原⼦性（Atomicity） 原⼦性是指事务包含的所有操作要么全部成功，要么全部失败回滚。
失败回滚的操作事务，将不能对事务有任何影响。
2. ⼀致性（Consistency） ⼀致性是指事务必须使数据库从⼀个⼀致性状态变换到另⼀个⼀致性状态，也就是说⼀个事务执⾏之前和执⾏之后都必须处于⼀致性状态。
例如：A和B进⾏转账操作，A有200块钱，B有300块钱；当A转了100块钱给B之后，他们2个⼈的总额还是500块钱，不会改变。
3. 隔离性（Isolation） 隔离性是指当多个⽤户并发访问数据库时，⽐如同时访问⼀张表，数据库每⼀个⽤户开启的事务，不能被其他事务所做的操作⼲扰(也就是事务之间的隔离)，多个并发事务之间，应当相互隔离。
例如同时有T1和T2两个并发事务，从T1⾓度来看，T2要不在T1执⾏之前就已经结束，要么在T1执⾏完成后才开始。
将多个事务隔离开，每个事务都不能访问到其他事务操作过程中的状态；就好⽐上锁操作，只有⼀个事务做完了，另外⼀个事务才能执⾏。
4. 持久性（Durability） 持久性是指事务的操作，⼀旦提交，对于数据库中数据的改变是永久性的，即使数据库发⽣故障也不能丢失已提交事务所完成的改变。
事务的隔离级别 事务的隔离级别从低到⾼分别是：读未提交，读已提交，可重复读，串⾏化，这四个隔离级别可以分别解决脏读，不可重复读，幻读的问题。
先介绍⼀下不存在事务隔离级别的时候会出现的情况 很明显的看出，旺财对A添加的20块不翼⽽飞了，这就是“数据丢失”，对事务不加任何锁（不存在事务隔离），就会导致这种问题。
读未提交 操作：写数据的时候添加⼀个X锁（排他锁），也就是在写数据的时候不允许其他事务进⾏写操作，但是读不受限制，读不加锁。
这样就可以解决了多个⼈⼀起写数据⽽导致了“数据丢失”的问题，但是会引发新的问题——脏读。
脏读：读取了别⼈未提交的数据。
数据库事务的四种隔离级别
数据库事务的四种隔离级别数据库事务的隔离级别有4种，由低到⾼分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable 。
⽽且，在事务的并发操作中可能会出现脏读，不可重复读，幻读。
下⾯通过事例⼀⼀阐述它们的概念与联系。
Read uncommitted读未提交，顾名思义，就是⼀个事务可以读取另⼀个未提交事务的数据。
事例：⽼板要给程序员发⼯资，程序员的⼯资是3.6万/⽉。
但是发⼯资时⽼板不⼩⼼按错了数字，按成3.9万/⽉，该钱已经打到程序员的户⼝，但是事务还没有提交，就在这时，程序员去查看⾃⼰这个⽉的⼯资，发现⽐往常多了3千元，以为涨⼯资了⾮常⾼兴。
但是⽼板及时发现了不对，马上回滚差点就提交了的事务，将数字改成3.6万再提交。
分析：实际程序员这个⽉的⼯资还是3.6万，但是程序员看到的是3.9万。
他看到的是⽼板还没提交事务时的数据。
这就是脏读。
Read committed读提交，顾名思义，就是⼀个事务要等另⼀个事务提交后才能读取数据。
事例：程序员拿着信⽤卡去享受⽣活（卡⾥当然是只有3.6万），当他买单时（程序员事务开启），收费系统事先检测到他的卡⾥有3.6万，就在这个时候！！程序员的妻⼦要把钱全部转出充当家⽤，并提交。
当收费系统准备扣款时，再检测卡⾥的⾦额，发现已经没钱了（第⼆次检测⾦额当然要等待妻⼦转出⾦额事务提交完）。
程序员就会很郁闷，明明卡⾥是有钱的…分析：这就是读提交，若有事务对数据进⾏更新（UPDATE）操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。
但在这个事例中，出现了⼀个事务范围内两个相同的查询却返回了不同数据，这就是不可重复读。
Repeatable read重复读，就是在开始读取数据（事务开启）时，不再允许修改操作事例：程序员拿着信⽤卡去享受⽣活（卡⾥当然是只有3.6万），当他埋单时（事务开启，不允许其他事务的UPDATE修改操作），收费系统事先检测到他的卡⾥有3.6万。
数据库事务隔离级别与并发控制详解
数据库事务隔离级别与并发控制详解随着数据库的广泛应用，对于数据库事务隔离级别和并发控制的需求也越来越高。
为了保证数据库的数据一致性和可靠性，数据库系统采用了事务隔离级别和并发控制机制。
本文将详细介绍数据库事务隔离级别和并发控制的概念和原理，以及不同隔离级别的特点和应用场景。
首先，我们来了解什么是事务隔离级别。
事务隔离级别指的是多个事务同时运行时彼此之间的影响程度，它提供了一种机制来控制事务的隔离程度，以确保事务在并发环境下执行的可靠性。
数据库管理系统定义了四个标准的事务隔离级别，分别为读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。
读未提交是最低级别的隔离级别，它允许一个事务读取到另一个事务尚未提交的数据。
这个隔离级别最容易导致脏读（Dirty Read）问题，即一个事务读取到了由另一个未提交事务所修改的数据。
读已提交是数据库系统的默认隔离级别，它保证一个事务读取到的数据是已经提交的数据，解决了脏读的问题。
但是读已提交隔离级别可能导致不可重复读（Non-repeatable Read）的问题，即一个事务多次读取同一数据时，得到的结果不一致。
为了解决不可重复读的问题，可重复读隔离级别引入了额外的机制。
在该隔离级别下，一个事务多次读取同一数据时，会得到一致的结果，即使其他事务修改了该数据。
可重复读隔离级别解决了不可重复读的问题，但依然可能导致幻读（Phantom Read）的问题。
幻读指的是在一个事务中的两次查询过程中的数据行的数量发生了不一致的情况。
最高级别的事务隔离级别是串行化，该级别通过对事务进行加锁的方式来实现隔离。
串行化隔离级别确保所有事务按照顺序依次执行，避免了脏读、不可重复读和幻读的问题。
但是串行化的隔离级别会导致系统的并发性能大幅下降，因此在实际应用中很少使用。
除了事务隔离级别，数据库还需要采取并发控制的措施来保证事务的并发执行安全可靠。
数据库事务隔离级别设置
数据库事务隔离级别设置你知道吗？数据库就像是一个大仓库，里面存着各种各样的数据，每天都有很多人在拿取、修改、更新这些数据。
就像你去超市买东西，别人排队等着结账，你要是拿错东西了，搞个乌龙，那可就麻烦了。
所以，数据库为了避免这种情况发生，就有了事务隔离级别的设定。
这就好像是超市的规则，给每个人划定好范围，不让大家发生冲突。
今天就来聊聊，数据库事务的四个隔离级别，看看它们怎么保障我们数据库的“井井有条”。
首先得明白什么是事务。
简单来说，事务就是一组操作，要么全部成功，要么全部失败，不能有半点马虎。
比如，你去银行转账，得先从A账户扣钱，再往B账户存钱。
如果中间卡住了，扣了钱没存进去，那就不行了，得保证这两步操作要么都成功，要么都不做。
可是，问题来了，万一在你转账的时候，别人也在同时修改账户数据，可能就会出现问题。
为了解决这个问题，数据库就给我们提供了事务隔离级别，避免这种“并发冲突”发生。
你说这事儿有多重要？想想看，如果你在修改数据的时候，不小心被别人的操作干扰了，那可就成了笑话。
假如你打算删除一条数据，可这时候另一个人也在查看这条数据，结果你删了它，他还看着那条数据，那不就闹了个大乌龙吗？所以数据库就给我们提供了四个等级的“隔离防护”，每个级别的安全防护能力都不一样。
咱们一个一个来看。
第一个级别叫“读未提交”。
这个名字听起来挺不靠谱的，读了就能提交。
什么意思呢？就是说在这个级别下，一个事务可以读取另一个事务还没提交的数据。
换句话说，你正在修改的数据，别人也能看到，哪怕你还没做完呢。
你想啊，这种情况容易发生什么？如果你在改数据，别人提前看了，可能看到了你还没完工的“半成品”数据，这就是“脏读”现象。
这种情况听起来像是过早吃到没有熟透的东西，想想都让人不舒服。
然后是“读已提交”。
这个级别相对靠谱点，至少在读取数据时，别人修改的数据得等到提交之后才能看见。
简单说就是，别人只能看到你修改完并提交的“正式数据”，不再看到半成品。
人大金仓KingbaseES数据库中事务的隔离级别
KingbaseES数据库中事务的隔离级别并发操作虽然可以改善数据库系统的资源利用率和短事务的响应时间，但是在运行中必须对并发事务加以控制，否则会引发一些问题。
SQL92 标准对这些情况进行了分类，并提出了解决办法。
由于一个事务可能包含多个SQL 语句，SQL 语句是顺序执行的。
T1 和 T2 两个事务在一个数据库上并发执行，可能有如下类型的问题：1）读“脏”数据（Dirty Read）事务 T1 更新了一个数据，并且在 T1 提交或者回滚前，另外一个事务T2读取了那个数据。
如果 T1 这个时候回滚，那么T2就读取了一个未提交的虚假的值，即“脏”数据。
2）不可重复读（Non-Repeatable 或 Fuzzy Read）事务 T1 读取了一个数据。
这个时候另外一个事务 T2 修改或者删除了这个数据并且提交了。
如果 T1 尝试再读取一次这个数据，它就会发现它再次读到的数据和以前不一样或者根本就不存在了。
3）幻象读（Phantom Read）事务 T1 读取了若干个满足某个查询条件的数据。
这个时候事务 T2 创建了一个数据恰好也满足 T1 的这个查询条件。
如果这个时候 T1 再次根据这个查询条件进行读取，它会发现会多出了部分数据。
很显然，高并发度带来了数据的不一致，这些情况一些是用户不愿意见到，一些则是无法接受的。
用户需要在高并发带来的高性能和数据的一致性之间做取舍。
SQL92 标准提出了事务隔离级别，来解决上面的问题。
表1 事务的隔离级别四个隔离级别从上到下对事务执行的并发程度进行了不同程度的限制，更加严格的限制在带来更好的数据一致性的同时，也会损失更多并发带来的高性能。
实际使用中，隔离级别并不是越高就越好，大多数情况下应用并不需要很高的数据一致性。
相反的，在多用户环境下，更强调的是并发度。
所以综合考虑选取一个折中的办法往往能达到最优的效果。
KingbaseES 向用户提供两种隔离级别：读已提交(Read committed)和可串行化(Serializable)。
数据库的四种隔离级别
数据库的四种隔离级别数据库的事务：⼀个逻辑⼯作单元，在⼯作单元的⼀系列操作要么全部执⾏，要么全部不执⾏。
四个特性：ACID，原⼦性（定义），⼀致性（事务开始前，事务结束后，数据库的完整性没有被破坏），隔离性（四个级别），持久性（事务完成后，对表的修改是永久的）。
问题来了：A、数据库的完整性：数据库数据在逻辑上的⼀致性，正确性，有效性和相容性。
完整性约束：1.实体完整性，每⼀⾏是表⾥唯⼀的实体；2.域完整性，表中的列必须满⾜数据类型约束（取值范围，数据类型）；3.参照完整性，两个表的主关键字和外关键字⼀致，防⽌数据丢失或者⽆意义的数据在数据库扩散；4.⽤户定义的完整性。
四个隔离级别：1.Read uncommited。
⼀个事务可以读取另外⼀个未提交事务的数据。
读取到事务未提交但已经改变的数据，⽽后事务回滚，数据未改变，为脏读。
2.Read commited，⼀个事务要等到另⼀个事务提交后才能读数据。
在这⼀级别下，读锁在select完成后就释放，写锁在事务提交后才释放。
所以⼀个事务先读数据，⽽后由另外⼀个事务update了表，等该事务结束后，第⼀个事务再次读表的时候数据发⽣了变化，为不可重复读。
3.Repeatable read，在读事务未提交时，不允许修改操作。
不可重复度对应的是修改（update）操作，如果是insert操作，记录条数不⼀致的情况可能会发⽣，为幻读。
4.Serializable，事务串⾏化顺序执⾏。
避免脏读，不可重复度，幻读，但是导致数据库性能低。
这个时候，会不会对数据库实现隔离级别的原理产⽣了兴趣？先来介绍⼀下数据库的锁：1.共享锁（S锁）：⼜称读锁，对数据对象加上S锁后，其他事务只能再对数据对象加S锁，⽽不能加X锁。
2.排它锁（X锁）：⼜称写锁，对数据对象加上X锁后，其他事务⽆法加锁，直到X锁被释放。
锁的规则：⾼并发出现的问题：丢失修改，脏读，不可重复度，幻读。
1.⼀级封锁协议：事务T修改数据R之前（并不是事务开始）必须先对其加X锁，事务结束（commit+rollback）后释放。
sqlserver 事务级别
sqlserver 事务级别
SQL Server 中有四种事务隔离级别，它们分别是 READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ 和SERIALIZABLE。
事务隔离级别决定了一个事务能够看到其他事务所
做的改变的程度，以及其他事务能够看到该事务所做的改变的程度。
1. READ UNCOMMITTED，在这个级别下，一个事务可以看到其他
事务尚未提交的修改。
这意味着它可以读取到未被其他事务确认的
数据，可能会导致脏读、不可重复读和幻读的问题。
2. READ COMMITTED，这是 SQL Server 默认的事务隔离级别。
在这个级别下，一个事务只能看到已经提交的数据修改。
这可以避
免脏读的问题，但仍然可能出现不可重复读和幻读的问题。
3. REPEATABLE READ，在这个级别下，一个事务在执行期间看
到的数据是一致的，即使其他事务对数据进行了修改。
这可以避免
脏读和不可重复读的问题，但仍然可能出现幻读的问题。
4. SERIALIZABLE，这是最严格的事务隔禅级别。
在这个级别下，事务之间是完全隔离的，可以避免脏读、不可重复读和幻读的问题，
但可能会导致性能下降，因为它会对数据进行加锁以确保事务的隔
离性。
选择合适的事务隔离级别取决于应用程序的需求和对数据一致
性的要求。
需要根据具体的业务场景和性能需求来进行权衡和选择。
同时，需要注意不同的隔离级别可能会对并发性能产生影响，需要
综合考虑。
oracle 的隔离级别
Oracle数据库提供了多种隔离级别，用于控制并发事务之间的数据访问和操作的一致性。
以下是Oracle数据库中常见的隔离级别：
1. 读未提交（Read Uncommitted）：最低级别的隔离级别，允许一个事务读取到另一个事务未提交的数据，可能导致脏读、不可重复读和幻读的问题。
2. 读已提交（Read Committed）：一个事务只能接受到已提交的数据，避免了脏读问题。
但在一个事务内可能会出现不可重复读和幻读的问题。
3. 可重复读（Repeatable Read）：确保在一个事务内多次读取同一数据时，结果始终保持一致。
其他并发事务对该数据进行的修改不会影响到当前事务。
4. 串行化（Serializable）：最高级别的隔离级别，保证事务之间的完全隔离。
通过强制事务串行执行，避免了各种并发问题，包括脏读、不可重复读和幻读。
较高的隔离级别通常会带来较高的并发控制开销，可能会对性能产生一定的影响。
因此，在设置隔离级别时需要根据应用的需求和并发访问的特点进行权衡。
Oracle还提供了一些特定的隔离级别设置选项，例如可序列化（Serializable）会话级别和快照隔离级别等，用于进一步定制并发控制策略。
可以使用`SET TRANSACTION`语句或通过应用程序设置隔离级别。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
事务隔离级别（transaction isolation levels ）：隔离级别就是对对事务
并发控制的等级。
实现技术：为了实现隔离级别通常数据库采用锁（Lock ），一般在编程的时候只需要设置隔离等级，至于具体采用什么锁则由数据库来设置。
分类：ANSI / ISO SQL 将其分为串行化（SERIALIZABLE ）、可重复读（REPEATABLE READ ）、读已提交（READ COMMITED ）、读未提交（READ UNCOMMITED ）四个等级。
串行化（SERIALIZABLE ）：所有事务都一个接一个地串行执行，但不能并发执行。
这样可以避免幻读（phantom reads ）。
实现技术：对于基于锁来实现并发控制的数据库来说，串行化要求在执行范围查询（如选取年龄在10到30之间的用户）的时候，需要获取范围锁（range lock ）。
如果不是基于锁实现并发控制的数据库，则检查到有违反串行操作的事务时，需要滚回该事务。
可重复读（REPEATABLE READ ）：所有被Select 获取的数据都不能被修改。
这样就可以避免不可重复读（一个事务前后读取数据不一致的情况）。
但是却没有办法控制幻读，因为这个时候其他事务不能更改所选的数据，但是可以增加数据，因为前一个事务没有范围锁。
实现技术：通过“共享读锁”和“排他写锁”实现。
读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。
读已提交（READ COMMITED ）：被读取的数据可以被其他事务修改。
这样就可能导致不可重复读。
也就是说，事务的读取数据的时候获取读锁，但是读完之后立即释放（不需要等到事务结束），而写锁则是事务提交之后才释放。
释放读锁之后，就可能被其他事物修改数据。
该等级也是SQL Server 默认的隔离等级。
实现技术：这可以通过“瞬间共享读锁”和“排他写锁”实现。
读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。
事务隔离级
transaction isolation levels
串行化读取
SERIALIZABLE
可重复读REPEATABLE
读已提交 READ COMMITED 读未提交 READ UNCOMMITED
读未提交（READ UNCOMMITED）：这是最低的隔离等级，允许其他事务看到没有提交的数据。
这种等级会导致脏读（Dirty Read）。
允许脏读取，但不允许更新丢失。
实现技术：如果一个事务已经开始写数据，则另外一个数据则不允许同时进行写操作，但允许其他事务读此行数据。
该隔离级别可以通过“排他写锁”实现。
综上述，可以等到下面的表格：
注:事物隔离级别是依据一个事物进行查询（Select，可能是一次或多次）时的数据是否“正确”为依据而定义的。
（理解）
补充：
更新丢失（Lost update）
1、两个事务都同时更新一行数据，但是第二个事务却中途失败退出，导致对数据的两个修改都失效了。
这是因为系统没有执行任何的锁操作，因此并发事务并没有被隔离开来。
2、脏读：事物一读到了事物二尚未提交的数据（如果事物二失败回滚的情况下，则事物一读到的数据则是无效的，或者说垃圾）
产生级别：读未提交
解决需要级别：读已提交
3、不可重复读：事物一在二次或多次读取数据时，读到了不同的数据。
原因是事物二在中间修改了其中的数据。
产生级别：读已提交
解决需要级别：可重复读
4、幻读：事物一修改了部分数据，事物二添加了新的并且符合事物一的条件的数据。
造成事物一发现有新的数据没有修改，称幻觉。
产生级别：可重复读
解决需要级别：串行化
问题的提出
数据库是要被广大客户所共享访问的，那么在数据库操作过程中很事务隔离级别可能出现以下几种不确定情况。
更新丢失（Lost update）
两个事务都同时更新一行数据，但是第二个事务却中途失败退出，导致对数据的两个修改都失效了。
这是因为系统没有执行任何的锁操作，因此并发事务并没有被隔离开来。
脏读（Dirty Reads）
一个事务开始读取了某行数据，但是另外一个事务已经更新了此数据但没有能够及时提交。
这是相当危险的，因为很可能所有的操作都被回滚。
不可重复读（Non-repeatable Reads）
一个事务对同一行数据重复读取两次，但是却得到了不同的结果。
它包括以下情况：（1）事务T1读取某一数据后，事务T2对其做了修改，当事务T1再次读该数据时得到与前一次不同的值。
（2）幻读（Phantom Reads）：事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据（这里并不要求两次查询的SQL语句相同）。
这是因为在两次查询过程中有另外一个事务插入数据造成的。