MySQL事务回顾

本文深入探讨了数据库事务的四大特性:原子性、一致性、隔离性和持久性,并详细解析了事务并发可能导致的问题,如丢失更新、脏读、不可重复读和幻读。同时,介绍了事务的四种隔离级别,包括读未提交、读已提交、可重复读和序列化,以及它们如何影响事务间的相互作用。

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

事务

一个session中所进行的所有操作,要么全部成功,要么全部失败,作为单个逻辑工作单位执行的一系列操作,会满足四大特性:
原子性(Atomicity):事务作为一个整体被执行 ,要么全部执行,要么全部不执行
一致性(Consistency):保证数据库状态从一个一致状态转变为另一个一致状态
隔离性(Isolation):多个事务并发执行时,一个事务的执行不应影响其他事务的执行
持久性(Durability):一个事务一旦提交,对数据库的修改应该永久保存

事务并发的问题

丢失更新: 一个事务的更新覆盖了另外一个事务的更新
脏读:一个事务读取了另一个事务未提交的数据
不可重复读:不可重复读的重点是修改,同样条件下两次读取结果不同,也就是说,被读取的数据可以被其它事务修改
幻读:幻读的重点在于新增或者删除,同样条件下两次读出来的记录数不一样

事务的隔离级别有哪几种

隔离级别决定了一个session中的事务可能对另一个session中的事务的影响。
ANSI标准定义了4个隔离级别,MySQL的InnoDB都支持
MySQL默认的隔离级别是可重复读(REPEATABLE READ)
读未提交(READ UNCOMMITTED):最低级别的隔离,通常又称为dirty read,它允许一个事务读取另一个事务还没 commit 的数据,这样可能会提高性能,但是会导致脏读问题
读已提交(READ COMMITTED):在一个事务中只允许对其它事务已经 commit 的记录可见,该隔离级别不能避免不可重复读问题
可重复读(REPEATABLE READ):在一个事务开始后,其他事务对数据库的修改在本事务中不可见,直到本事务 commit 或 rollback。但是,其他事务的 insert/delete 操作对该事务是可见的,也就是说,该隔离级别并不能避免幻读问题。在一个事务中重复 select 的结果一样,除非本事务中 update 数据库
序列化(SERIALIZABLE):最高级别的隔离,只允许事务串行执行
### MySQL事务传播机制及其用法 #### 什么是MySQL事务传播行为? 在分布式数据库环境中,当多个事务相互依赖或者需要协调执行时,事务传播行为定义了一个事务如何影响另一个事务的行为。虽然MySQL本身并不直接支持像Java Spring框架那样的显式事务传播概念[^1],但在实际应用中,可以通过配置隔离级别以及手动控制事务边界来实现类似的传播效果。 #### MySQL中的事务特性 为了更好地理解事务传播行为,在讨论之前先回顾一下ACID原则: - **Atomicity (原子性)**:整个事务要么全部完成,要么完全不发生。 - **Consistency (一致性)**:事务完成后,数据应保持一致状态。 - **Isolation (隔离性)**:并发事务之间互不影响。 - **Durability (持久性)**:一旦提交,更改永久保存到存储介质上。 这些属性共同构成了事务的基础,并间接决定了事务之间的交互方式和传播模式[^2]。 #### 常见的事务传播类型 尽管MySQL原生API并未提供类似于Spring AOP中的`@Transactional`注解所描述的具体传播选项(例如REQUIRED, REQUIRES_NEW等),但通过合理设置SQL语句顺序、使用START TRANSACTION/COMMIT命令以及调整全局或会话级别的参数可以模拟某些场景下的需求: | 类型 | 描述 | |-----------------|----------------------------------------------------------------------------------------| | REQUIRED | 如果当前存在活动事务,则加入该事务;否则创建新事务 | | SUPPORTS | 支持运行在一个已有事务上下文中,但如果不存在任何现有事务则以非事务形式继续 | | MANDATORY | 要求必须有一个正在运行的事务环境 | | REQUIRES_NEW | 总是挂起现有的事务并启动一个新的独立事务 | | NOT_SUPPORTED | 完全禁用事务处理 | 需要注意的是上述表格仅作为理论参考模型,在纯MySQL环境下无法直接映射成具体功能实现[^3]。 #### 实现跨表操作的一致性和隔离性的方法 假设我们希望两个不同表上的更新能够遵循某种特定类型的事务传播逻辑,比如强制开启新的独占事务来进行修改操作,下面给出一段伪代码示例展示可能的做法: ```sql -- 开始第一个事务 START TRANSACTION; SAVEPOINT before_update_table_a; -- 设置保存点以便回滚单步错误 UPDATE table_a SET column='value' WHERE condition; IF ERROR THEN ROLLBACK TO SAVEPOINT before_update_table_a; END IF; -- 提交前一部分工作成果 COMMIT; -- 启动第二个全新的事务用于后续步骤 START TRANSACTION; INSERT INTO table_b (...) VALUES (...); COMMIT; ``` 此脚本片段展示了如何利用标准SQL语法构建简单的分阶段提交流程,从而达到近似于REQUIRES_NEW的效果[^4]。 #### 配置读副本的影响 回到最初的提示信息“Add an RDS MySQL read replica”,如果目标架构涉及只读实例部署的话,那么还需要特别注意主从复制延迟对于整体业务连续性评估带来的潜在风险。因为即使源端完成了所有必要的写入动作并且成功结束关联事务链路,下游消费者仍有可能暂时看不到最新版本的数据记录直到同步过程彻底完毕为止[^5]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值