人人都会AI编程

24.3 事务使用规范与避坑指南

更新时间：2026-07-11

事务是保证数据一致性的核心工具，但如果使用不当，它也会成为性能杀手和线上故障的源头。本节将实际开发中必须遵守的事务使用规范与常见踩坑场景逐一梳理，每个规范都有明确的“应做”与“避免”，以及背后的原因。

24.3.1 事务使用核心规范

规范一：严格控制事务粒度，事务尽可能短小

  • 应做：将事务限制在最小必要操作范围内，只包裹需要原子性保证的 SQL。比如完成一笔转账，事务只包含查询余额、扣款、增加余额三条语句，不要把生成日志、发送通知等额外操作放在事务内。
  • 避免：在事务中调用外部服务（如 Redis、消息队列、HTTP 接口），或在事务内进行大量复杂计算。外部调用的耗时无法控制，会无限拉长事务时间，导致锁长时间不释放、Undo Log 膨胀、主从延迟加剧。
  • 原因：长事务持有锁和 MVCC 快照的时间更长，阻塞其他事务，可能导致严重锁等待甚至雪崩。生产环境中，事务平均执行时长应控制在毫秒级，超过秒级就应视为长事务，需要拆分或优化。

规范二：手动管理事务，明确开启和结束

  • 应做：在代码中使用 START TRANSACTION（或 BEGIN）显式开启事务，逻辑执行完毕后明确执行 COMMIT 或 ROLLBACK。
  • 避免：依赖 MySQL 的自动提交机制在复杂业务中充当事务边界。自动提交每条 SQL 单独提交，无法保证多条语句的原子性。
  • 代码示例：
// 正确示例（Java 伪代码）
Connection conn = dataSource.getConnection();
try {
    conn.setAutoCommit(false);
    // 执行业务 SQL 1
    // 执行业务 SQL 2
    conn.commit();
} catch (Exception e) {
    conn.rollback();
} finally {
    conn.setAutoCommit(true);
    conn.close();
}

规范三：正确处理异常，务必回滚

  • 应做：在 catch 块中无条件调用 rollback()，确保事务失败时数据库状态完全恢复。
  • 避免：仅仅打印日志或向上层抛出异常而不回滚，会导致事务未提交也未回滚，连接状态残留，后续在该连接上执行的其他 SQL 可能被误包含进前一个未完成的事务。
  • 特别注意：当数据库连接从连接池获取时，如果之前的使用者因为异常未正确 rollback 且未重置自动提交状态，下一个拿到该连接的线程可能会被“半开事务”影响，这是典型的“连接泄露”导致的隐形事务问题。

规范四：合理选择隔离级别

  • 应做：默认使用 InnoDB 推荐的 REPEATABLE READ（可重复读），它能满足绝大多数业务的一致性需求。在特定场景（如数据统计、宽表刷新）中，如果对幻读容忍度较高且需要更高并发，可考虑将隔离级别调整为 READ COMMITTED。
  • 避免：随意使用 SERIALIZABLE 级别，它会强制所有读写加锁，并发能力极差。除非是极端一致性场景且数据量很小。
  • 原因：REPEATABLE READ 通过间隙锁（Gap Lock）大幅降低了幻读风险，在订单生成、库存扣减等场景中实际效果和大规模验证都证明可靠。READ COMMITTED 可以配合 binlog_format = ROW 在主从场景使用，但要注意避免幻读。

规范五：避免事务嵌套，慎用 SAVEPOINT

  • 应做：大部分框架（如 Spring）的事务传播行为（PROPAGATION_REQUIRED）会复用已有事务，这本质上是“伪嵌套”。应从架构层面避免编写可能嵌套开启独立事务的逻辑。
  • 避免：直接创建多个嵌套的独立事务（如在存储过程中重复开启事务）。MySQL 不支持标准 SQL 的嵌套事务，但通过 SAVEPOINT 可以部分模拟回滚到保存点。保存点过多会增加开销，且显式 SAVEPOINT 带来的回滚不释放已持有锁，需谨慎使用。

24.3.2 避坑指南：常见问题与解决方案

坑1：大事务导致系统卡顿甚至主从延迟雪崩

  • 表象：一次批量操作（如处理几百万条数据、大量更新全表字段）在一个事务中执行，执行时间十几分钟，期间相关行锁一直不释放，其他业务操作全部阻塞；主库 Binlog 瞬间产生大量日志，从库回放耗时极长，延迟急剧增加。
  • 解决方案：将大事务拆分为小批量处理。例如，每 500 或 1000 条提交一次事务，循环执行直到全部完成。同时运维侧可设置 max_execution_time 拦截执行时间过长的 SQL。
  • 典型错误：
-- 错误：整个表更新在一个大事务中
UPDATE orders SET status = 'archived' WHERE create_time < '2023-01-01';
-- 正确：拆分批量更新
DELIMITER //
CREATE PROCEDURE batch_update_orders()
BEGIN
  DECLARE done INT DEFAULT FALSE;
  DECLARE batch_size INT DEFAULT 1000;
  DECLARE min_id BIGINT DEFAULT 0;
  DECLARE max_id BIGINT;
  REPEAT
    START TRANSACTION;
    UPDATE orders SET status = 'archived'
    WHERE id > min_id AND id <= min_id + batch_size
      AND create_time < '2023-01-01';
    COMMIT;
    SET min_id = min_id + batch_size;
    -- 加短暂 sleep 避免对磁盘连续冲击
    DO SLEEP(0.1);
  UNTIL done END REPEAT;
END //

坑2：锁等待超时或死锁频繁

  • 表象：事务中先更新某些行，再更新其他行；不同事务的更新顺序不一致，导致循环等待死锁。或者事务中先不加锁查询，然后基于结果做更新，在高并发下出现“丢失更新”。
  • 解决方案：
  • 固定资源访问顺序：所有事务更新多张表的顺序保持一致（如总是先用户表再订单表）。
  • 尽量缩短锁定时间：将非必须的查询放到事务外，事务内只做必要的读写。
  • 使用 SELECT … FOR UPDATE 提前锁定需要操作的行，避免后续 surprise（但注意只在必要时锁定）。
  • 代码示例（库存扣减正确姿势）：
START TRANSACTION;
-- 1. 先锁定目标行，防止其他事务并发扣减
SELECT stock FROM inventory WHERE product_id = 1 FOR UPDATE;
-- 2. 判断库存是否充足
IF stock >= 1 THEN
  UPDATE inventory SET stock = stock - 1 WHERE product_id = 1;
END IF;
COMMIT;

坑3：隐式提交导致事务意外终止或数据不一致

  • 表象：在一个事务中执行了 DDL 语句（如 ALTER TABLE、TRUNCATE 等），或者使用了某些特定语句（如 CREATE INDEX、DROP TABLE），MySQL 会隐式提交当前事务。后续操作在本以为还在事务内的情况下变成了自动提交，破坏了原子性。
  • 解决方案：严格禁止在应用程序的事务内执行 DDL。DDL 变更应由独立的运维流程处理，且 DDL 期间需要锁表，与业务高峰时间错开。MySQL 8.0 支持原子 DDL，DDL 失败可回滚，但仍然会隐式提交事务，这点需特别注意。
  • 避坑清单：会产生隐式提交的语句包括但不限于：CREATE TABLE、ALTER TABLE、DROP TABLE、TRUNCATE、LOCK TABLES、UNLOCK TABLES、BEGIN（当有事务时）。

坑4：误解“自动提交”导致数据丢失

  • 表象：在 MySQL 命令行中直接输入 DELETE / UPDATE，没有手动开启事务，发现删错了无法回滚。
  • 原因：MySQL 默认开启自动提交，每运行一条 DML 语句自动提交一次。没有手动 BEGIN 的话，UPDATE 完成后已经固化，无法用 ROLLBACK 挽救。
  • 解决方法：
  • 在生产库进行修改前，务必先执行 BEGIN 或用 START TRANSACTION 包裹，确认无误后手动 COMMIT。
  • 长时间使用的客户端连接，如果断开连接，未提交的事务会自动回滚，不要依赖“断开连接回滚”作为唯一保障，要养成主动管理事务的习惯。

坑5：连接池中的事务残留

  • 表象：应用偶尔出现莫名其妙的锁等待，或者明明已经提交了上个请求的数据，下一个请求似乎仍然看到了未提交的数据版本。查看数据库发现大量闲置连接处于“Sleep”状态且带有 InTransaction 标志。
  • 原因：连接池归还连接时，前一个事务未彻底结束（没有 COMMIT 或 ROLLBACK）或者未将 autocommit 重置为 true。下一个业务线程从池中拿到该连接后，在未开新事务的情况下，所有 SQL 都跑在前一个事务的上下文中。
  • 解决方案：
  • 中间件（如 Spring 事务管理器）配置好 spring.datasource.hikari.auto-commit=false 管理事务时，确保事务结束时必定执行 commit 或 rollback，并在 finally 中重置 autocommit。
  • 设置连接池属性（如 HikariCP 的 rollback-on-return），在连接归还池时强制回滚未提交事务。

坑6：事务与异步操作的错误混用

  • 表象：在事务内发起异步消息或 RPC 调用，并期望异步操作仅在事务提交后生效。结果异步任务实际在事务提交前执行，导致读到未提交数据或操作无效。
  • 解决方案：绝对不能将异步调用放入事务内部。正确方式是以“最大努力通知”或“事务消息”模式实现：先提交事务，然后判断提交结果，再发送 MQ；或者使用本地消息表，将消息插入业务库同一事务，异步扫描该表发送。
  • 伪代码对比：
// 错误：在事务内发消息
@Transactional
public void createOrder(Order order) {
    orderDao.insert(order);
    mqTemplate.send("orderCreateTopic", order); // 事务未提交，消息消费端可能找不到数据
}

// 正确：事务提交后发送消息
public void createOrder(Order order) {
    TransactionTemplate.execute(status -> {
        orderDao.insert(order);
        return null;
    });
    // 事务已提交
    mqTemplate.send("orderCreateTopic", order);
}

坑7：不必要的事务

  • 表象：一个只读查询的业务，代码也开启了事务（甚至带着 @Transactional）。这不仅浪费连接资源，还可能导致长事务快照无意义持有，影响 Undo 清理。
  • 解决方案：查询操作如果不需要一致性读的快照，设置为只读事务或直接不开启事务。Spring 中可用 @Transactional(readOnly = true) 标记只读事务，让 MySQL 在一定程度上优化锁开销（InnoDB 中 readOnly 提示目前只对 SELECT 产生轻微影响，但仍表明意图）。

小结：事务是保障一致性的利器，但每一步滥用都可能埋下隐患。记住一个总原则：让事务尽可能小、尽可能快、尽可能简单。当遇到高并发复杂业务时，先确保索引和事务边界清晰，再配合锁策略，绝大部分事务相关问题都可以从根本上避免。