事务是mysql中用于保证一组数据库操作要么全部成功要么全部失败的核心机制，合理使用事务能有效避免数据不一致问题，但若使用不当也会引发性能下降、锁冲突等风险。理解事务的特性并结合业务场景设计事务逻辑，是后端开发者的必备技能。
事务的核心特性ACID
mysql的事务遵循ACID四大特性，这是理解事务行为的基础：
- 原子性（Atomicity）：事务中的所有操作要么全部完成，要么全部不完成，不会存在中间状态。
- 一致性（Consistency）：事务执行前后，数据库的完整性约束没有被破坏，数据符合业务规则。
- 隔离性（Isolation）：多个事务并发执行时，一个事务的执行不会被其他事务干扰，不同隔离级别对应不同的并发控制效果。
- 持久性（Durability）：事务提交后，对数据的修改是永久的，即使数据库出现故障也不会丢失。
mysql事务的基础操作
在mysql中，默认情况下每条SQL语句都是一个独立的事务，执行后自动提交。如果需要手动控制事务，可通过以下命令操作：
-- 关闭自动提交，开启手动事务控制 SET autocommit = 0; -- 开启事务（等价于上面的关闭自动提交，二选一即可） START TRANSACTION; -- 执行一组业务SQL UPDATE account SET balance = balance - 100 WHERE id = 1; UPDATE account SET balance = balance + 100 WHERE id = 2; -- 如果执行过程中没有错误，提交事务 COMMIT; -- 如果出现异常，回滚事务，所有操作失效 ROLLBACK; -- 恢复自动提交 SET autocommit = 1;
不同业务场景的事务使用建议
适合使用事务的场景
当业务操作涉及多个写操作，且这些操作之间存在依赖关系时，必须使用事务：
- 转账类操作：转出账户扣钱和转入账户加钱必须同时成功或失败。
- 订单创建流程：创建订单主表、插入订单商品明细、扣减库存这三个操作需要绑定在一个事务中。
- 批量数据更新：比如批量修改用户状态，需要保证要么所有用户都修改成功，要么全部回滚。
不适合使用事务的场景
- 单条写操作：单条INSERT、UPDATE、DELETE本身就有原子性，不需要额外包裹事务。
- 包含大量耗时非数据库操作的流程：比如事务中包含了调用第三方接口、生成大量文件等操作，会导致事务持有锁的时间过长，引发锁冲突。
- 只读查询操作：普通的查询不需要事务，除非需要保证多次查询的数据一致性，可开启只读事务。
事务隔离级别的选择建议
mysql支持四种事务隔离级别，不同级别对应不同的并发能力和数据一致性保障：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 适用场景 |
|---|---|---|---|---|
| READ UNCOMMITTED（读未提交） | 可能 | 可能 | 可能 | 几乎不使用，数据一致性无保障 |
| READ COMMITTED（读已提交） | 不可能 | 可能 | 可能 | 对一致性要求不高，并发要求高的场景，比如大部分互联网业务 |
| REPEATABLE READ（可重复读） | 不可能 | 不可能 | 可能（InnoDB通过间隙锁基本解决） | mysql默认隔离级别，适合大部分需要数据一致性的业务 |
| SERIALIZABLE（串行化） | 不可能 | 不可能 | 不可能 | 对数据一致性要求极高，并发量极低的场景，比如金融核心交易 |
查看和设置隔离级别的SQL如下：
-- 查看当前会话的隔离级别 SELECT @@transaction_isolation; -- 设置当前会话的隔离级别为读已提交 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 设置全局隔离级别（需要重启会话生效） SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
避免长事务的实战技巧
长事务是指执行时间很长的事务，会占用大量的锁资源，还可能导致undo log堆积，影响数据库性能，需要尽量避免：
- 事务中只包含必要的数据库操作，把非数据库操作（比如参数校验、业务逻辑计算、调用外部接口）放到事务外面。
- 避免在事务中执行耗时查询，比如查询大量数据、关联多张表的复杂查询。
- 设置事务执行超时时间，在代码中捕获超时异常，主动回滚事务。
- 定期监控数据库中的长事务，通过
information_schema.innodb_trx表可以查看当前运行的事务：
-- 查询运行时间超过60秒的事务 SELECT trx_id, trx_started, trx_mysql_thread_id, trx_query FROM information_schema.innodb_trx WHERE trx_started < NOW() - INTERVAL 60 SECOND;
死锁的处理与预防
当多个事务互相持有对方需要的锁，且都在等待对方释放锁时，就会发生死锁。mysql的InnoDB引擎会自动检测死锁，并回滚其中一个事务来打破死锁。我们可以通过以下方式减少死锁的发生：
- 所有事务都按照相同的顺序获取锁，比如更新账户时都先更新id小的账户，再更新id大的账户。
- 尽量使用主键更新数据，避免无索引的更新操作导致锁表。
- 控制事务的大小，减少事务中持有锁的数量和时间。
- 在代码中捕获死锁异常，进行重试操作，示例Java代码如下：
public void transferMoney(int fromId, int toId, int amount) {
int retryCount = 3;
while (retryCount > 0) {
try {
// 获取数据库连接，关闭自动提交
Connection conn = dataSource.getConnection();
conn.setAutoCommit(false);
// 执行转账SQL
String sql1 = "UPDATE account SET balance = balance - ? WHERE id = ?";
PreparedStatement ps1 = conn.prepareStatement(sql1);
ps1.setInt(1, amount);
ps1.setInt(2, fromId);
ps1.executeUpdate();
String sql2 = "UPDATE account SET balance = balance + ? WHERE id = ?";
PreparedStatement ps2 = conn.prepareStatement(sql2);
ps2.setInt(1, amount);
ps2.setInt(2, toId);
ps2.executeUpdate();
// 提交事务
conn.commit();
break;
} catch (SQLException e) {
// 判断是否为死锁异常，mysql死锁错误码为1213
if (e.getErrorCode() == 1213 && retryCount > 1) {
retryCount--;
try {
conn.rollback();
} catch (SQLException ex) {
// 回滚异常处理
}
} else {
// 其他异常直接抛出
throw new RuntimeException(e);
}
}
}
}
总结
在项目中合理使用mysql事务，需要结合业务场景判断是否需要使用事务，选择合适的隔离级别，避免长事务和死锁问题。遵循事务操作的最小化原则，只把必要的数据库操作放在事务中，才能既保证数据一致性，又不影响数据库性能。
mysqltransactionacidrollback修改时间：2026-06-10 23:36:26