事务的ACID特性与MySQL隔离级别实战
聊到数据一致性，绕不开的就是事务。我刚开始做游戏后端那会儿，对事务的理解就是「要么全做，要么全不做」。后来被线上问题教育了几次，才真正体会到这四个字母背后的分量。
ACID：数据库事务的四大护法
ACID 是事务的四个基本特性。说白了，就是数据库保证数据不出错的四条铁律。
原子性（Atomicity）
原子性要求事务里的操作，要么全部成功，要么全部失败。不能出现做一半的情况。
游戏场景举例：玩家购买道具，需要同时扣金币和加道具。如果金币扣了，道具没加上，玩家肯定要骂娘。反过来，道具加了金币没扣，那游戏就亏了。
我遇到过最典型的原子性问题，是在一个跨服拍卖行系统里。玩家出价竞拍，需要冻结金币、记录出价、更新拍卖状态。这三个操作必须在一个事务里完成。有一次因为网络抖动，事务提交了一半就断了，结果玩家金币被冻结了，但出价记录没写进去。嗯，那天的客诉量直接爆表。
一致性（Consistency）
一致性保证事务执行前后，数据都符合业务规则。比如玩家的金币不能为负数，等级不能超过上限。
游戏场景举例：玩家升级时，经验值不能超过当前等级上限。如果经验值溢出了，必须触发升级逻辑。这就是一致性约束。
我个人习惯在数据库层面也加一些约束，比如 CHECK 约束或者触发器。虽然应用层也能做校验，但数据库层面的约束是最后一道防线。你想想看，万一代码里有 bug，数据库还能兜个底。
隔离性（Isolation）
隔离性解决的是并发问题。多个事务同时操作同一份数据时，不能互相干扰。
游戏场景举例：两个玩家同时抢最后一个限时礼包。如果没有隔离性，两个人都可能看到库存还剩1个，然后都成功购买。结果就是超卖。
我曾经在活动服务器上踩过这个坑。双十一活动，限时礼包被抢购一空，但后台数据显示卖出了120%的库存。原因就是事务隔离级别设置得太低，导致并发读取到了脏数据。从那以后，涉及库存扣减的操作，我全部要求使用可重复读级别。
持久性（Durability）
持久性保证事务一旦提交，数据就不会丢失。哪怕数据库宕机了，重启后数据还在。
游戏场景举例：玩家充值成功，钻石到账。如果这时候服务器断电了，重启后钻石必须还在。这就是持久性的价值。
MySQL事务隔离级别：选对了少踩坑
MySQL 的 InnoDB 引擎支持四种隔离级别。从低到高，并发性能递减，但数据安全性递增。
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 游戏场景适用性 |
|---|---|---|---|---|
| 读未提交（READ UNCOMMITTED） | 可能 | 可能 | 可能 | ❌ 基本不用 |
| 读已提交（READ COMMITTED） | 不会 | 可能 | 可能 | ✅ 日志、排行榜 |
| 可重复读（REPEATABLE READ） | 不会 | 不会 | 可能（InnoDB解决） | ✅ 核心业务（推荐） |
| 串行化（SERIALIZABLE） | 不会 | 不会 | 不会 | ⚠️ 极少使用 |
读未提交：别碰它
这个级别允许读取其他事务未提交的数据。说白了就是「脏读」。在游戏里，你读到别人还没确认的数据，那结果就是各种诡异。
举个例子：A玩家正在购买道具，事务还没提交。B玩家查询库存，读到了A玩家扣减后的数据。结果A玩家取消购买了，库存又恢复了。但B玩家已经根据错误数据做了决策。这游戏还怎么玩？
我个人建议，游戏服务器永远不要使用读未提交。哪怕只是查询操作，也可能读到中间状态的数据。我曾经在一个内部工具里用过，结果报表数据天天对不上，排查了两天才发现是隔离级别的问题。
读已提交：适合读多写少的场景
这个级别解决了脏读问题，但存在不可重复读。也就是说，同一个事务里，两次读取同一行数据，结果可能不一样。
游戏场景举例：排行榜系统。玩家查看排行榜时，数据实时变化是正常的。读已提交完全够用，而且性能比可重复读好一些。
但要注意，如果你在同一个事务里先查询玩家金币，再根据金币做扣减操作，读已提交就不安全了。因为两次查询之间，可能有其他事务修改了金币数量。
可重复读：游戏服务器的首选
这是 MySQL 的默认隔离级别，也是我推荐游戏业务使用的级别。它保证了同一个事务里，多次读取同一行数据，结果始终一致。
游戏场景举例：玩家背包操作。查询背包、扣减道具、增加道具，这些操作在同一个事务里，必须保证数据的一致性视图。
我记得有一次优化充值流程，把隔离级别从可重复读降到了读已提交，想着提升并发性能。结果上线后，部分玩家充值后钻石到账了，但充值记录查不到。原因就是读已提交下，事务内的两次查询结果不一致。赶紧回滚，再也不敢乱改隔离级别了。
关于幻读，InnoDB 通过间隙锁（Gap Lock）在可重复读级别下解决了幻读问题。所以实际使用中，可重复读已经足够安全。
串行化：安全但慢
串行化强制事务串行执行，完全避免了并发问题。但代价是性能极差，并发量直接掉到个位数。
游戏里几乎用不到这个级别。除非是那种极其敏感的操作，比如跨服战结算、全服活动发奖，而且并发量极低的情况下才会考虑。
如果你发现业务需要用到串行化，我建议先反思一下架构设计。是不是锁的粒度太大了？能不能用乐观锁或者分布式锁替代？串行化是最后的选择，不是最优解。
实战中的选择建议
说了这么多，到底怎么选？我给出一个简单粗暴的建议：
- 核心业务（充值、背包、交易）：使用可重复读。这是最稳妥的选择。
- 非核心业务（日志、统计、排行榜）：使用读已提交。性能更好，数据一致性要求不高。
- 读未提交和串行化：基本不用。前者不安全，后者太慢。
另外，别忘了在代码层面也做好并发控制。隔离级别只是数据库层面的保障，应用层的乐观锁、分布式锁同样重要。你想想看，如果所有问题都指望数据库解决，那架构就太脆弱了。
最后说一句，隔离级别的选择不是一劳永逸的。随着业务发展，你可能需要调整。但记住一个原则：宁可慢一点，不能错一点。数据一致性出了问题，修复成本远高于性能优化成本。