事务级别及相关内容

本文详细阐述了数据库事务的四大核心特性:原子性、一致性、隔离性和持久性,并介绍了乐观锁与悲观锁的概念,以及四种不同的事务隔离级别,包括它们如何解决并发操作中的常见问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

事务的四个属性:原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持久性(durability)。

1.原子性(Atomic)
最重要的原则,也是最容易理解的原则。被事务管理的所有方法,要么一起被提交,要么一起回滚。

2.一致性(Consistency)
事务在系统完整性中实施一致性,如果事务成功地完成,那么系统中所有变化将正确地应用,系统处于新有效状态。如果在事务中出现错误,那么系统中的所有变化将自动地回滚,系统返回到原始状态。

3.隔离性(Isolation)
在隔离状态执行事务,使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务,运行在相同的时间内,执行相同的功能,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化,为了防止事务操作间的混淆,必须串行化或序列化请求,使得在同一时间仅有一个请求用于同一数据。重要的是,在隔离状态执行事务,系统的状态有可能是不一致的,在结束事务前,应确保系统处于一致状态。但是在每个单独的事务中,系统的状态可能会发生变化。如果事务不是在隔离状态运行,它就可能从系统中访问数据,而系统可能处于不一致状态。通过提供事务隔离,可以阻止这类事件的发生。

4.持久性(Durability)
持久性意味着一旦事务执行成功,在系统中产生的所有变化将是永久的。应该存在一些检查点防止在系统失败时丢失信息。甚至硬件本身失败,系统的状态仍能通过在日志中记录事务完成的任务进行重建。

数据库锁概念:
在数据库中有两种基本的锁类型:排它锁(Exclusive Locks,即X锁)和共享锁(Share Locks,即S锁)。当数据对象被加上排它锁时,其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取,但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。
从程序员的角度看,锁分为以下两种类型:
1.乐观锁(Optimistic Lock)
乐观锁假定在处理数据时,不需要在应用程序的代码中做任何事情就可以直接在记录上加锁、即完全依靠数据库来管理锁的工作。一般情况下,当执行事务处理时SQL Server会自动对事务处理范围内更新到的表做锁定。
2.悲观锁(Pessimistic Lock)
悲观锁对数据库系统的自动管理不感冒,需要程序员直接管理数据或对象上的加锁处理,并负责获取、共享和放弃正在使用的数据上的任何锁。

事务隔离级别
一个事务必须与其它事务进行隔离的程度。较低的隔离级别可以增加并发,但代价是降低数据的正确性。相反,较高的隔离级别可以确保数据的正确性,但可能对并发产生负面影响。

数据库并发操作存在的异常情况:
1. 更新丢失(Lost update):两个事务都同时更新一行数据但是第二个事务却中途失败退出导致对数据两个修改都失效了这是系统没有执行任何锁操作因此并发事务并没有被隔离开来

2. 脏读取(Dirty Reads):一个事务开始读取了某行数据但是另外一个事务已经更新了此数据但没有能够及时提交。这是相当危险很可能所有操作都被回滚

3. 不可重复读取(Non-repeatable Reads):一个事务对同一行数据重复读取两次但是却得到了不同结果。例如在两次读取中途有另外一个事务对该行数据进行了修改并提交

4. 两次更新问题(Second lost updates problem):无法重复读取特例,有两个并发事务同时读取同一行数据然后其中一个对它进行修改提交而另一个也进行了修改提交这就会造成第一次写操作失效

5. 幻读(Phantom Reads):也称为幻像(幻影)。事务在操作过程中进行两次查询,第二次查询结果包含了第一次查询中未出现的数据(这里并不要求两次查询SQL语句相同)这是因为在两次查询过程中有另外一个事务插入数据造成的

为了避免上面出现几种情况在标准SQL规范中定义了4个事务隔离级别,不同隔离级别对事务处理不同 。

1.未授权读取(Read Uncommitted):也称未提交读。允许脏读取但不允许更新丢失,如果一个事务已经开始写数据则另外一个数据则不允许同时进行写操作但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。事务隔离的最低级别,仅可保证不读取物理损坏的数据。与READ COMMITTED 隔离级相反,它允许读取已经被其它用户修改但尚未提交确定的数据。

2. 授权读取(Read Committed):也称提交读。允许不可重复读取但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现,读取数据的事务允许其他事务继续访问该行数据,但是未提交写事务将会禁止其他事务访问该行。SQL Server 默认的级别。在此隔离级下,SELECT 命令不会返回尚未提交(Committed) 的数据,也不能返回脏数据。

3. 可重复读取(Repeatable Read):禁止不可重复读取和脏读取。但是有时可能出现幻影数据,这可以通过“共享读锁”和“排他写锁”实现,读取数据事务将会禁止写事务(但允许读事务),写事务则禁止任何其他事务。在此隔离级下,用SELECT 命令读取的数据在整个命令执行过程中不会被更改。此选项会影响系统的效能,非必要情况最好不用此隔离级。

4. 串行(Serializable):也称可串行读。提供严格的事务隔离,它要求事务序列化执行,事务只能一个接着一个地执行,但不能并发执行。如果仅仅通过 “行级锁”是无法实现事务序列化的,必须通过其他机制保证新插入的数据不会被刚执行查询操作事务访问到。事务隔离的最高级别,事务之间完全隔离。如果事务在可串行读隔离级别上运行,则可以保证任何并发重叠事务均是串行的。


隔离级别 更新丢失 脏读取 重复读取 幻读
未授权读取 N Y Y Y
授权读取 N N Y Y
可重复读取 N N N Y
串行 N N N N


Oracle 支持的 2 种事务隔离级别 Read committed 和 Serializable

根據官方資料,它們的區別如下:

动作 Read Committed Serializable
Dirty write Not possible Not possible
Dirty read Not possible Not possible
Nonrepeatable read Possible Not possible
Phantoms Possible Not possible

Read committed 是默认的隔离级别。
对于Read committed ,事务中的查询只能看到在此查询之前( 而非事务开始之前 )提交的数据。 由于 oracle 不会因为查询数据而阻止另外一个事务修改数据,因此数据可以在一个事务中的 2 次查询中,查到不同的结果。因此 可能出现 nonrepeatable read and phantoms 的情况

对于serializable transactions ,当2次执行同一条查询语句的时候(就是两次执行查询,就是说执行完第一个 .executeQuery ,然后执行第二个 .executeQuery ),如果在第一个 .executeQuery 开始执行而另外一个事务已经开始修改数据,并且已经提交,那么两次读取的数据是另外一个事务修改前的数据。如果在第一个 .executeQuery 之前,另外一个事务修改了数据,那么两次读取的数据是另外一个事务修改后的数据。

这恰恰反映了, repeatable read ,两次结果一致

这与 Read committed 完全不同, 要是 Read committed ,第一个 .executeQuery 未执行完第二事务,而在第二个 .executeQuery 前第二个事务执行完毕,那么第一个 .executeQuery 得到的是初始数据,而第二个 .executeQuery 得到的是修改后的数据

恰恰说明了 nonrepeatable read ,两次结果不一致的情况
<think>我们正在讨论MySQL事务管理及隔离级别。用户希望详细了解MySQL事务及其隔离级别。根据引用内容,MySQL提供四种事务隔离级别:读未提交、读提交、可重复读和串行化。不同级别在并发控制、数据一致性和性能方面有不同表现。此外,InnoDB引擎在可重复读级别下通过MVCC和间隙锁避免大部分幻读问题。回答结构:1.事务基本概念:介绍事务的ACID特性2.隔离级别详解:分别解释四种隔离级别,以及它们如何解决脏读、不可重复读、幻读问题3.设置隔离级别:如何设置全局、会话级和单个事务的隔离级别4.InnoDB的MVCC机制:解释多版本并发控制如何支持事务隔离5.隔离级别的选择建议:根据应用场景推荐合适的隔离级别6.示例:通过SQL示例演示不同隔离级别的行为7.相关问题:生成相关问题注意:引用内容中已经提到了一些关键点,如InnoDB在可重复读级别下避免幻读,以及设置隔离级别的命令。我们将整合这些信息。</think>### MySQL 事务管理及隔离级别详解 #### 一、事务基础概念 **事务(Transaction)** 是数据库操作的逻辑单元,需满足 **ACID** 特性: - **原子性(Atomicity)**:操作要么全部成功,要么全部回滚 - **一致性(Consistency)**:事务前后数据状态合法 - **隔离性(Isolation)**:并发事务互不干扰 - **持久性(Durability)**:提交后数据永久保存 ```sql START TRANSACTION; -- 开启事务 UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; COMMIT; -- 提交事务 ``` #### 二、隔离级别详解 MySQL 提供四种隔离级别,解决并发问题: | 隔离级别 | 脏读 | 不可重复读 | 幻读 | 实现机制 | 性能 | |------------------|------|------------|------|------------------------------|--------| | **READ UNCOMMITTED** (读未提交) | ✓ | ✓ | ✓ | 无锁 | 最高 | | **READ COMMITTED** (读已提交) | ✗ | ✓ | ✓ | 快照读(MVCC) | 较高 | | **REPEATABLE READ** (可重复读) | ✗ | ✗ | △⁺ | MVCC + 间隙锁 | 中等 | | **SERIALIZABLE** (串行化) | ✗ | ✗ | ✗ | 全表锁 | 最低 | > **注**: > - **脏读**:读取到未提交的数据 > - **不可重复读**:同一查询返回不同结果(数据被修改) > - **幻读**:同一查询返回新插入的行 > - **⁺**:InnoDB 在 REPEATABLE READ 下通过间隙锁避免大部分幻读[^2][^3] #### 三、隔离级别设置方式 ```sql -- 全局设置(影响所有新会话) SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- 会话级设置(仅当前连接有效) SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 仅对下一个事务有效 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; START TRANSACTION; -- 开启事务... -- 查看当前隔离级别(MySQL 8.0+) SELECT @@GLOBAL.transaction_isolation, @@SESSION.transaction_isolation; ``` #### 四、MVCC 多版本并发控制 InnoDB 实现隔离级别的核心机制: ```mermaid graph LR A[事务开始] --> B[分配事务ID] B --> C[创建ReadView] C --> D{查询数据} D -->|检查版本可见性| E[返回符合版本的数据] ``` - 每个数据行有隐藏字段:`DB_TRX_ID`(最后修改的事务ID)和 `DB_ROLL_PTR`(回滚指针) - 读操作访问**历史版本快照**,写操作创建新版本 - 解决读写冲突,实现非锁定读[^2] #### 五、不同隔离级别行为演示 ##### 场景:账户余额查询 ```sql -- 会话1(事务A) START TRANSACTION; SELECT balance FROM accounts WHERE id=1; -- 返回1000 -- 会话2(事务B)更新数据 START TRANSACTION; UPDATE accounts SET balance=900 WHERE id=1; COMMIT; SELECT balance FROM accounts WHERE id=1; -- 不同隔离级别结果: ``` | 隔离级别 | 第二次查询结果 | 说明 | |------------------|----------------|---------------------| | READ UNCOMMITTED | 900 | 读到未提交的修改 | | READ COMMITTED | 1000 → 900 | 读到已提交的新数据 | | REPEATABLE READ | 1000 → 1000 | 保持首次读取结果 | | SERIALIZABLE | 1000 → 1000 | 事务B会被阻塞 | #### 六、隔离级别选型建议 1. **READ COMMITTED** - 适用场景:多数OLTP系统(如电商订单) - 优势:平衡性能与一致性 - 注意点:需处理不可重复读问题 2. **REPEATABLE READ**(MySQL默认级别) - 适用场景:财务系统、对数据一致性要求高的场景 - 优势:避免不可重复读和幻读(InnoDB优化) - 注意点:间隙锁可能导致死锁[^3] 3. **READ UNCOMMITTED/SERIALIZABLE** - 特殊场景:数据仓库(只读分析)、银行核心系统 - 谨慎使用:前者数据易错,后者性能差 > **最佳实践**: > - 使用 `SHOW ENGINE INNODB STATUS` 监控锁竞争 > - 通过 `EXPLAIN` 分析查询是否触发间隙锁 > - 关键业务操作显式指定隔离级别 #### 七、事务控制语句 ```sql START TRANSACTION; -- 显式开启事务 SAVEPOINT sp1; -- 创建保存点 ROLLBACK TO sp1; -- 回滚到保存点 SET autocommit=0; -- 关闭自动提交(默认=1) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值