SQL事务的核心概念
SQL事务是一组不可分割的数据库操作序列，这些操作要么全部执行成功，要么全部不执行，是数据库保证数据一致性的基础单元。要理解事务如何确保数据一致性，首先需要掌握事务的ACID四大特性：
- 原子性（Atomicity）：事务中的所有操作是一个整体，要么全部完成，要么全部回滚，不会出现部分执行的情况。
- 一致性（Consistency）：事务执行前后，数据库的完整性约束不会被破坏，数据状态符合业务规则。
- 隔离性（Isolation）：多个事务并发执行时，一个事务的执行不会被其他事务干扰，各自的操作相互隔离。
- 持久性（Durability）：事务提交后，其对数据库的修改会永久保存，即使数据库发生故障也不会丢失。
事务的基本操作语法
在SQL中，事务的控制主要通过几个核心语句实现，不同数据库的基础语法通用性较强，以下以MySQL为例展示基本用法：
-- 关闭自动提交，开启事务 SET autocommit = 0; -- 显式开启事务（可选，关闭自动提交后直接执行操作也会进入事务上下文） START TRANSACTION; -- 执行一组业务操作，比如用户A向用户B转账 -- 用户A余额减100 UPDATE account SET balance = balance - 100 WHERE user_id = 1; -- 用户B余额加100 UPDATE account SET balance = balance + 100 WHERE user_id = 2; -- 操作全部成功，提交事务 COMMIT; -- 如果出现异常，回滚事务，所有操作失效 ROLLBACK;
需要注意的是，DDL语句（如CREATE、ALTER、DROP）会隐式提交当前事务，因此在事务中不要穿插执行这类语句，避免事务提前提交导致一致性无法保障。
事务隔离级别与数据一致性
事务的隔离级别决定了并发事务之间的可见性规则，不同的隔离级别可以解决不同程度的一致性问题，SQL标准定义了四种隔离级别，具体差异如下表所示：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 一致性保障程度 |
|---|---|---|---|---|
| 读未提交（READ UNCOMMITTED） | 可能出现 | 可能出现 | 可能出现 | 最低 |
| 读已提交（READ COMMITTED） | 不会出现 | 可能出现 | 可能出现 | 中等 |
| 可重复读（REPEATABLE READ） | 不会出现 | 不会出现 | 可能出现（InnoDB引擎通过间隙锁可避免） | 较高 |
| 串行化（SERIALIZABLE） | 不会出现 | 不会出现 | 不会出现 | 最高 |
查看和设置事务隔离级别的SQL示例如下：
-- 查看当前会话的事务隔离级别 SELECT @@transaction_isolation; -- 设置当前会话的事务隔离级别为可重复读 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- 设置全局事务隔离级别为读已提交 SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
选择隔离级别时需要权衡一致性和性能，隔离级别越高，并发性能越低，一般业务场景使用读已提交或可重复读即可满足大部分一致性需求。
确保数据一致性的最佳实践
1. 事务范围尽可能小
事务持有数据库资源的时间越长，发生锁冲突的概率越高，同时也会增加一致性问题的风险。因此要尽量缩短事务的执行时间，只把必须保证原子性的操作放在事务中，避免在事务中执行耗时操作比如远程接口调用、大文件处理等。
-- 错误示例：事务中包含非数据库操作逻辑，导致事务持有时间过长 START TRANSACTION; UPDATE order SET status = 1 WHERE order_id = 1001; -- 模拟耗时操作，实际业务中不要这样做 -- 调用远程接口发送通知 -- 生成订单报表文件 COMMIT; -- 正确示例：只把数据库操作放在事务中 START TRANSACTION; UPDATE order SET status = 1 WHERE order_id = 1001; INSERT INTO order_log (order_id, content) VALUES (1001, '订单状态更新为已支付'); COMMIT; -- 事务提交后再执行发送通知、生成报表等非数据库操作
2. 合理处理事务异常
在代码中执行事务操作时，必须捕获可能出现的异常，一旦发生异常就执行回滚操作，避免部分操作生效导致数据不一致。以下是Java中使用JDBC处理事务的示例：
Connection conn = null;
try {
conn = DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306/test", "root", "password");
// 关闭自动提交，开启事务
conn.setAutoCommit(false);
// 执行SQL操作
PreparedStatement ps1 = conn.prepareStatement("UPDATE account SET balance = balance - 100 WHERE user_id = 1");
ps1.executeUpdate();
PreparedStatement ps2 = conn.prepareStatement("UPDATE account SET balance = balance + 100 WHERE user_id = 2");
ps2.executeUpdate();
// 提交事务
conn.commit();
} catch (SQLException e) {
e.printStackTrace();
if (conn != null) {
try {
// 出现异常回滚事务
conn.rollback();
} catch (SQLException ex) {
ex.printStackTrace();
}
}
} finally {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
}3. 避免长事务和锁表操作
长事务会占用数据库连接资源，还可能导致undo log过度膨胀，影响数据库性能。另外要尽量避免使用LOCK TABLES这类锁表语句，InnoDB引擎的行级锁已经可以满足大部分并发场景的需求，锁表会大幅降低并发能力，还容易引发死锁。
4. 结合业务规则校验一致性
事务只能保证数据库层面的原子性和隔离性，部分业务层面的一致性规则还需要在代码中额外校验。比如在转账场景中，除了用事务保证两个余额更新操作的原子性，还需要在更新前校验转出账户余额是否充足，避免更新后出现负余额的不一致状态。
START TRANSACTION;
-- 先查询转出账户余额
SELECT balance INTO @balance FROM account WHERE user_id = 1;
-- 校验余额是否充足
IF @balance >= 100 THEN
UPDATE account SET balance = balance - 100 WHERE user_id = 1;
UPDATE account SET balance = balance + 100 WHERE user_id = 2;
COMMIT;
ELSE
-- 余额不足，回滚事务
ROLLBACK;
END IF;常见事务问题排查
如果业务中出现数据一致性问题，可以按照以下思路排查：
- 检查事务是否正确开启和提交，是否存在未提交的事务导致锁等待。
- 确认当前事务隔离级别是否符合业务需求，是否存在隔离级别过低导致的脏读、不可重复读问题。
- 查看数据库慢查询日志，是否存在长事务占用资源。
- 检查代码中异常处理逻辑，是否遗漏了事务回滚的操作。