InnoDB 事务与锁机制：隔离级别、MVCC 与死锁排查

关系型数据库最核心的能力之一是事务。很多业务正确性问题，本质上不是 SQL 写错，而是没有理解并发下事务、锁和隔离级别的行为。库存超卖、重复扣款、状态回退、死锁频发，都可能来自错误的事务边界。

InnoDB 的事务能力很强，但它不会替你自动设计业务一致性。你必须知道什么时候会加锁、锁住什么范围、读到的是快照还是当前版本。

ACID 的工程意义

ACID 不是面试术语。它在生产中对应四个问题：

• Atomicity：一组操作要么全成功，要么全失败。
• Consistency：业务约束在事务前后都成立。
• Isolation：并发事务之间如何互相可见。
• Durability：提交后的数据在故障后仍然存在。

数据库提供基础能力，业务一致性仍需应用设计。例如订单支付成功后扣库存、写流水、改订单状态，这些动作是否在同一事务里，直接决定故障时系统能否恢复。

MVCC

InnoDB 使用 MVCC 支持一致性非锁定读。普通 SELECT 在可重复读隔离级别下通常读取事务开始时的快照，不会阻塞写，也不会被写阻塞。

但当前读会读取最新版本并加锁，例如：

SELECT * FROM inventory WHERE sku_id = ? FOR UPDATE;
UPDATE inventory SET stock = stock - 1 WHERE sku_id = ?;

当前读适合需要并发控制的业务，例如扣库存、领取优惠券、分配任务。

隔离级别

MySQL 常见隔离级别：

• READ COMMITTED：每次语句读取已提交数据。
• REPEATABLE READ：事务内一致快照，MySQL 默认。
• SERIALIZABLE：最强隔离，性能成本高。

在 READ COMMITTED 下，不同语句可能读到不同结果。在 REPEATABLE READ 下，普通快照读稳定，但当前读仍会看到最新数据。

不要以为隔离级别越高越好。更高隔离会带来更多锁竞争。关键是匹配业务需求。

行锁与索引

InnoDB 行锁基于索引。如果 UPDATE 条件没有命中合适索引，可能扫描并锁住大量记录，甚至造成严重阻塞。

例如：

UPDATE users SET status = 'disabled' WHERE email = ?;

如果 email 没有索引，这条语句可能扫描大量行。并发下，影响会被放大。

锁优化的第一步往往是确认更新和删除条件是否有高选择性索引。

间隙锁与 Next-Key Lock

在 REPEATABLE READ 下，为防止幻读，InnoDB 可能使用间隙锁和 Next-Key Lock。范围查询加锁时，不仅锁已有记录，还可能锁住记录之间的间隙，阻止其他事务插入。

例如：

SELECT * FROM orders
WHERE user_id = 10 AND amount BETWEEN 100 AND 200
FOR UPDATE;

如果索引设计不合理，锁范围可能比你想象的大。生产中范围加锁要非常谨慎，尤其是高并发写入表。

死锁排查

死锁并不一定是数据库故障，它是并发系统的正常现象。关键是降低频率，并让应用能重试。

查看最近死锁：

SHOW ENGINE INNODB STATUS\G

常见原因：

• 多个事务以不同顺序更新资源。
• 缺少索引导致锁范围过大。
• 事务过长。
• 用户交互或远程调用放在事务内。
• 批量更新一次锁太多行。

解决思路：

• 统一资源更新顺序。
• 缩短事务时间。
• 增加合适索引。
• 小批量提交。
• 对死锁错误做安全重试。

事务边界

事务内不要做慢操作，例如调用外部 API、等待消息、执行复杂计算。事务越长，锁持有越久，冲突概率越高。

推荐把事务边界控制在数据库必要写入范围内。外部系统协调用状态机、消息和补偿处理。

总结

InnoDB 事务和锁机制是业务正确性的基础。理解 MVCC、当前读、行锁、间隙锁和死锁，才能在高并发下写出稳定系统。数据库能保证事务语义，但业务要负责定义正确的事务边界和并发控制策略。