Java学习手册：数据库事务相关知识

在这里插入图片描述

一、事务的概念与特性

概念：事务是数据库中一系列操作的集合，这些操作要么全部成功，要么全部失败，是一个不可分割的工作单位。例如，在银行转账系统中，从一个账户扣款和向另一个账户存款这两个操作必须作为一个事务来执行，要么都成功，要么都失败，否则就会导致数据不一致。
ACID 特性 ：
- 原子性（Atomicity） ：事务中的操作要么全部完成，要么全部不完成，不会停留在中间状态。例如，在网上书店的订单处理中，如果订单创建和库存减少这两个操作属于同一个事务，那么它们要么都成功执行，要么都回滚，不会出现只创建了订单但未减少库存的情况。
- 一致性（Consistency） ：事务执行前后，数据库从一个一致状态转换到另一个一致状态。例如，在航空售票系统中，事务确保在机票预订后，座位数量不会出现负数或超过实际可用数量的情况。
- 隔离性（Isolation） ：并发执行的事务之间互不干扰，一个事务的执行不能被其他事务干扰。例如，在多用户同时访问在线购物网站时，事务隔离性确保一个用户的购物车更新不会影响其他用户的购物体验。
- 持久性（Durability） ：事务完成后，其对数据库的修改是永久的，即使系统发生故障也不会丢失。例如，银行转账完成后，即使服务器突然宕机，转账记录和账户余额的更新也不会丢失。

二、事务的类型

读写事务 ：对数据库进行读取和写入操作的事务。例如，在线学习平台中，学生提交作业和教师批改作业的操作通常属于读写事务，因为它们会更新数据库中的记录。
只读事务 ：只对数据库进行读取操作的事务。例如，在电商网站上浏览商品信息的操作通常属于只读事务，因为它只是查询数据库中的商品数据，而不会对其进行修改。

三、事务的并发问题

脏读：一个事务读取了另一个事务尚未提交的数据。例如，事务 A 读取了事务 B 更新但尚未提交的数据，之后事务 B 回滚，事务 A 读取到的数据就与数据库的实际状态不符。
不可重复读 ：在一个事务中，多次读取同一数据得到不同的结果。例如，事务 A 先读取了某条记录，然后事务 B 更新了这条记录并提交，事务 A 再次读取该记录时得到了不同的值。
幻读：一个事务在执行过程中，发现其他事务插入了新的数据，导致读取到的数据范围发生变化。例如，事务 A 按某种条件读取一组记录，事务 B 在这些记录中插入了新的满足条件的记录并提交，事务 A 再次按相同条件读取时，发现出现了新的记录。
丢失更新 ：两个或多个事务同时对同一数据进行更新，导致其中一个事务的更新被其他事务覆盖。例如，事务 A 和事务 B 都读取了同一账户的余额，进行更新后提交，后提交的事务覆盖了先提交的事务的更新结果。

四、事务的隔离级别

未提交读（Read Uncommitted） ：最低的隔离级别，允许脏读。事务可以看到其他事务尚未提交的更新。例如，在某些对数据一致性要求不高的日志系统中，可能会使用这个隔离级别以提高性能，但在大多数需要数据准确性的场景中不适用。
已提交读（Read Committed） ：避免了脏读，但仍然可能出现不可重复读和幻读。事务只能读取其他事务已经提交的数据。例如，在在线论坛中，用户查看帖子内容时，通常使用已提交读隔离级别，因为帖子内容一旦发布就会被提交，用户希望看到的是最新的内容，而不是担心重复读取的问题。
可重复读（Repeatable Read） ：确保同一个事务中多次读取同一数据得到相同的结果，避免了不可重复读和脏读，但仍然可能出现幻读。例如，在银行账户管理系统中，为确保在事务处理过程中账户余额的一致性，通常会使用可重复读隔离级别。
串行化（Serializable） ：最高的隔离级别，避免了脏读、不可重复读和幻读。事务之间完全隔离，按照顺序串行执行，但性能开销较大。例如，在涉及重要金融交易或高度敏感数据的场景中，可能会使用串行化隔离级别以确保数据的绝对一致性。

五、事务的传播行为

REQUIRED ：如果当前存在事务，则加入该事务；如果不存在，则创建一个新的事务。这是默认的传播行为。例如，在一个复杂的业务流程中，多个步骤的操作都可能需要在一个事务中执行，以确保整个流程的原子性。
SUPPORTS ：如果当前存在事务，则加入该事务；如果不存在，则以非事务的方式执行。例如，对于一些只读查询操作，如果存在事务则在事务中执行，否则单独执行，因为这些操作本身不会修改数据，对事务的依赖性较低。
MANDATORY ：如果当前存在事务，则加入该事务；如果不存在，则抛出异常。例如，在某些必须保证操作在事务环境下执行的场景中，如关键数据的更新操作，要求调用者必须提供事务环境，否则拒绝执行。
REQUIRES_NEW ：总是创建一个新的事务。如果当前存在事务，则将当前事务挂起，创建一个新的事务。例如，在一个分布式事务环境中，某些操作需要独立的事务边界以确保其原子性，即使在已有事务的环境下。
NOT_SUPPORTED ：以非事务的方式执行。如果当前存在事务，则将当前事务挂起。例如，对于一些明确不需要事务的操作，如简单的查询日志记录等，可以指定该传播行为以避免不必要的事务开销。
NEVER ：以非事务的方式执行。如果当前存在事务，则抛出异常。例如，对于某些明确设计为无事务的操作，如某些异步任务的触发操作，确保其不会受到事务环境的影响。
NESTED ：如果当前存在事务，则创建一个嵌套事务；如果不存在，则创建一个新的事务。嵌套事务是外部事务的一部分，对外部事务的回滚有影响。例如，在一个复杂的业务流程中，某些子操作可以设计为嵌套事务，以便在子操作失败时仅回滚该子操作，而不影响整个事务的其他部分（如果支持的话）。

六、事务的管理方式

自动提交 ：在自动提交模式下，每个 SQL 语句都被当作一个独立的事务来执行和提交。这种方式简单，但在进行多个相关操作时，无法保证它们的原子性。例如，在命令行工具中执行单个查询或更新语句时，默认通常处于自动提交模式。
手动提交 ：在手动提交模式下，需要显式地开始事务、提交事务或回滚事务。这提供了对事务边界的精确控制，适用于需要将多个操作组合成一个原子性事务的场景。例如，在开发复杂的业务逻辑时，如转账程序，需要手动控制事务的开始和结束以确保数据一致性。

七、数据库事务的实际应用

银行转账系统 ：确保资金从一个账户转移到另一个账户时，扣款和存款操作要么都成功，要么都失败，维护了账户余额的一致性。
在线购物平台 ：在订单创建过程中，涉及库存减少、订单状态更新等多个操作，事务确保这些操作要么全部完成，要么在出现问题时全部回滚，避免了超卖或订单信息不一致的情况。
库存管理系统 ：更新库存数量时，事务防止不同用户同时操作导致的数据不一致，确保库存计数的准确性。