1. 项目概述为什么并发控制与事务隔离是数据库的基石如果你用过任何一个稍微有点规模的在线系统无论是电商、社交还是企业内部应用大概率都遇到过这样的场景两个人同时想买最后一件商品结果都显示“库存充足”并下单成功或者你在后台修改一条数据的同时另一个同事在查询他看到的可能是你修改到一半的“脏数据”。这些问题本质上都是数据库在应对多个用户同时操作时没有处理好“并发控制”和“事务隔离”所导致的。“并发控制”和“事务隔离级别”这两个词听起来很学术但它们是保证数据库数据正确、一致的“交通规则”和“隔离带”。没有它们数据库世界就会乱成一锅粥数据错乱、丢失更新、读到无效中间状态等问题会层出不穷。我处理过不少生产环境的诡异Bug追根溯源很多都是因为开发初期对事务隔离级别理解不透或者在高并发场景下选错了隔离级别。这次我们就以MySQL这个最流行的开源关系型数据库为例彻底拆解并发控制的原理和事务隔离级别的实战意义。这不仅仅是应付面试题虽然面试必问更是每一位后端工程师、DBA乃至架构师必须内化的核心知识。理解了它们你才能写出在高并发下依然健壮的代码设计出数据强一致的系统。2. 核心概念拆解事务、并发与隔离在深入技术细节之前我们必须把几个最基础但又最容易混淆的概念掰扯清楚。很多问题就源于概念模糊。2.1 什么是数据库事务你可以把事务想象成一个“打包”操作。它把一组对数据库的读写操作比如扣减库存、生成订单、更新用户积分打包成一个不可分割的单元。这个单元必须满足ACID四个特性原子性事务内的所有操作要么全部成功要么全部失败回滚不存在中间状态。这通常由数据库的Undo Log回滚日志来保证。一致性事务执行前后数据库都必须处于一个一致的状态。这包括所有预定义的数据完整性约束如外键、唯一索引都必须得到满足。一致性是最终目标原子性、隔离性和持久性都是为了实现它。隔离性多个并发事务执行时一个事务的操作不应该影响其他事务。这是本次讨论的核心也是并发控制要解决的主要问题。持久性一旦事务提交它对数据的修改就是永久性的即使系统崩溃也不会丢失。这由Redo Log重做日志来保证。注意ACID中的“C”一致性是最容易被误解的。它并非指数据在分布式系统中的“最终一致性”而是指数据库本身定义的数据逻辑正确性。比如转账事务必须保证A账户减少的金额等于B账户增加的金额这个业务规则就是一致性约束。2.2 并发操作会带来哪些问题当多个事务不加控制地并发执行时会引发一系列经典问题隔离级别正是为了解决它们而设计的脏读事务A读到了事务B未提交的修改。如果事务B之后回滚了那么事务A读到的就是根本不存在的数据。例如你看到同事在编辑一份文档但还没保存你就把他编辑中的内容当成了最终版。不可重复读在同一个事务内两次读取同一条记录得到了不同的结果。这是因为在两次读取之间另一个事务提交了更新。例如你第一次查询账户余额是100元在事务没结束前再次查询发现变成了90元因为中间有扣款事务提交了。幻读在同一个事务内两次执行相同的范围查询得到了不同的记录数量。这是因为在两次查询之间另一个事务提交了插入或删除操作。例如你统计“状态为进行中的订单”数量第一次是10个第二次变成了11个因为中间有新订单被插入并提交了。不可重复读和幻读的区别这是面试高频考点。简单说不可重复读针对的是已存在行的数据内容被修改而幻读针对的是结果集的行数因为新增或删除而发生变化。前者用行锁可以解决后者通常需要间隙锁。2.3 事务隔离级别从宽松到严格的四级屏障为了解决上述并发问题SQL标准定义了四种隔离级别它们像一道道强度不同的屏障读未提交屏障最弱。一个事务能读到另一个事务未提交的修改。这会导致脏读、不可重复读和幻读。除非是只追求极致性能且对数据一致性毫无要求的场景如某些实时性要求极高的缓存否则几乎不会使用。读已提交这是Oracle等数据库的默认级别。一个事务只能读到另一个事务已经提交的修改。它解决了脏读但依然可能发生不可重复读和幻读。因为每次读到的都是其他事务提交后的最新快照。可重复读这是MySQL InnoDB存储引擎的默认隔离级别。它保证在同一个事务中多次读取同一行数据的结果是一致的。它解决了脏读和不可重复读但理论上在标准SQL下仍可能存在幻读。不过InnoDB通过多版本并发控制和间隙锁机制在这个级别下也基本解决了幻读问题。串行化屏障最强。所有事务按顺序一个接一个执行完全杜绝了并发问题。它通过强制事务串行执行来实现性能开销最大通常只在极端要求数据一致性且并发很低的场景下使用。这四种级别的隔离强度依次递增但性能开销也依次增大。选择哪个级别本质上是在数据一致性和系统性能之间做权衡。3. MySQL InnoDB的并发控制实现机制知道了问题脏读、不可重复读、幻读和目标四种隔离级别接下来最关键的是看MySQL的InnoDB引擎是如何实现这些隔离级别的。它的核心武器是两样锁和MVCC。3.1 锁机制悲观并发的基石锁是一种悲观的控制机制它假设冲突很可能发生因此在访问数据前先加锁防止其他事务干扰。InnoDB的锁主要分为两类共享锁也叫读锁。事务A对数据加了共享锁后其他事务可以继续加共享锁来读但不能加排他锁来写。SELECT ... LOCK IN SHARE MODE语句会加共享锁。排他锁也叫写锁。事务A对数据加了排他锁后其他事务既不能加共享锁读也不能加排他锁写。UPDATE、DELETE、INSERT以及SELECT ... FOR UPDATE语句会加排他锁。除了行锁InnoDB还有意向锁表级锁用于快速判断表中是否有行被锁定和间隙锁。间隙锁是InnoDB在可重复读级别下解决幻读的关键。它锁定的不是具体的某一行而是索引记录之间的“间隙”防止其他事务在这个间隙中插入新的记录。例如如果表中有id为1, 5, 10的记录那么间隙锁可能锁定(1,5)、(5,10)、(10, ∞)这些区间。实操心得SELECT ... FOR UPDATE是一个非常常用的语句用于在查询时就直接加上排他锁实现“先查后改”场景的并发安全。但务必注意它必须在事务中才有效并且要根据索引查询否则可能升级为表锁严重影响并发性能。3.2 MVCC乐观并发的魔法多版本并发控制是一种乐观的机制。它通过保存数据在某个时间点的多个版本来实现非锁定读从而大幅提升读操作的并发性能。这是InnoDB实现“读已提交”和“可重复读”隔离级别的核心技术。MVCC的关键在于每行记录都有两个隐藏字段DB_TRX_ID最近一次修改该行数据的事务ID。DB_ROLL_PTR指向该行数据在Undo Log中旧版本数据的指针构成一个版本链。此外每个事务在启动时都会获得一个全局递增的事务ID并且会生成一个当前系统活跃事务ID的视图数组。MVCC下的读操作快照读 当执行普通的SELECT语句非加锁读时InnoDB会基于当前事务的视图去判断版本链中的哪个版本对当前事务是可见的。判断规则的核心是数据版本的DB_TRX_ID是否小于当前事务ID并且不在活跃事务列表中。在读已提交级别每次执行SELECT都会生成一个新的快照Read View所以总能读到其他事务已提交的最新数据。在可重复读级别只在第一次执行SELECT时生成快照Read View并在整个事务期间复用这个视图因此实现了可重复读。MVCC与锁的关系MVCC主要用于解决读-写冲突实现无锁的快照读提升了读并发。而锁特别是排他锁用于解决写-写冲突确保同一时间只有一个事务能修改某行数据。两者协同工作共同保障了隔离性。4. 不同隔离级别的实战表现与配置理论说再多不如动手试试。我们通过一个简单的实验来直观感受不同隔离级别的区别。4.1 环境准备与实验设计首先我们创建一个测试表并插入数据CREATE TABLE account ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(50) DEFAULT NULL, balance int(11) DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB; INSERT INTO account (name, balance) VALUES (张三, 1000), (李四, 1000);我们打开两个MySQL客户端连接模拟两个并发的事务A和事务B。4.2 实验一脏读 vs 读已提交将当前会话的隔离级别设置为读未提交SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;事务A左窗口开启事务并修改数据但不提交START TRANSACTION; UPDATE account SET balance balance - 100 WHERE name 张三; -- 张三余额变为900事务B右窗口也设置为读未提交并查询SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; START TRANSACTION; SELECT balance FROM account WHERE name 张三; -- 此时会读到900事务B读到了事务A未提交的数据900这就是脏读。现在将事务B的隔离级别改为读已提交事务A保持未提交SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 重新查询 SELECT balance FROM account WHERE name 张三; -- 此时读到的仍然是1000事务B读不到未提交的数据了脏读被解决。但如果事务A提交了事务B再次查询就会读到900这就是不可重复读。4.3 实验二不可重复读 vs 可重复读将两个会话的隔离级别都设置为读已提交。事务B开启事务并第一次查询START TRANSACTION; SELECT balance FROM account WHERE name 张三; -- 假设读到1000事务A开启一个独立事务修改并提交START TRANSACTION; UPDATE account SET balance balance - 100 WHERE name 张三; COMMIT; -- 余额变为900事务B再次查询SELECT balance FROM account WHERE name 张三; -- 此时读到了900同一个事务B内两次查询结果不一致发生了不可重复读。将事务B的隔离级别改为可重复读并重复上述步骤。你会发现在事务B提交之前无论事务A如何修改提交事务B内部查询到的余额始终是第一次查询时的快照1000。不可重复读被解决。4.4 实验三幻读与间隙锁幻读的演示需要范围查询。准备数据account表有id为1, 3, 5的记录。事务A在可重复读级别下执行START TRANSACTION; SELECT * FROM account WHERE id 2 FOR UPDATE; -- 加锁查询期望锁住id2的记录这条语句不仅会给id3,5的记录加上行锁还会在(2, ∞)这个间隙加上间隙锁。事务B尝试插入START TRANSACTION; INSERT INTO account (id, name, balance) VALUES (4, 王五, 500); -- 这条语句会被阻塞因为id4落在事务A锁定的间隙(2, ∞)内所以插入操作被阻塞直到事务A提交。这就防止了幻读的产生。重要提示在MySQL中查看和设置隔离级别。查看当前会话隔离级别SELECT transaction_isolation;设置全局隔离级别重启后失效SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;设置当前会话隔离级别SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;生产环境修改默认隔离级别需谨慎通常在MySQL配置文件my.cnf中修改transaction-isolation参数。5. 生产环境中的选择、陷阱与优化了解了原理和表现最终要落到如何用上。隔离级别没有绝对的好坏只有适合与否。5.1 如何选择合适的隔离级别读已提交优点避免了脏读语句级的快照读让每次查询都能拿到已提交的最新数据对很多业务逻辑来说更直观。锁的持有时间相对较短减少锁竞争。缺点存在不可重复读和幻读风险。适用场景数据一致性要求不是极度严格但追求较高并发读性能的系统。许多互联网应用采用此级别配合应用层的乐观锁或状态机来避免更新冲突。可重复读MySQL默认优点解决了脏读和不可重复读并且InnoDB通过间隙锁在很大程度上避免了幻读提供了很强的一致性视图。缺点间隙锁可能带来更严重的锁竞争尤其是在全表扫描或范围更新时容易导致死锁。长时间未提交的事务会保留很老的快照可能导致Undo Log膨胀。适用场景对数据一致性要求很高的核心业务如金融账户余额操作。也是MySQL的“安全”默认值。个人建议对于大多数业务可以沿用MySQL默认的可重复读。但如果团队对间隙锁带来的死锁问题感到棘手并且业务逻辑能够容忍不可重复读例如基于状态或版本的更新可以考虑切换到读已提交这通常是Oracle DBA转向MySQL后的首选。串行化和读未提交则极少使用。5.2 常见陷阱与死锁分析即使理解了隔离级别死锁依然是高并发下的常客。一个典型场景事务AUPDATE table SET ... WHERE id 1;(持有id1的排他锁)事务BUPDATE table SET ... WHERE id 2;(持有id2的排他锁)事务AUPDATE table SET ... WHERE id 2;(尝试获取id2的锁等待B)事务BUPDATE table SET ... WHERE id 1;(尝试获取id1的锁等待A)互相等待形成死锁。InnoDB会检测到死锁并强制回滚其中一个代价较小的事务。避坑指南保持事务简短尽快提交或回滚缩短锁的持有时间。以固定的顺序访问多行数据如果所有事务都约定先操作id小的再操作id大的就能避免循环等待。为高频操作创建合适的索引UPDATE/DELETE ... WHERE条件如果没有索引会升级为表锁极易引发阻塞和死锁。使用SELECT ... FOR UPDATE时务必小心确保WHERE条件走索引且只锁定必要的行。启用死锁检测与设置合理超时innodb_deadlock_detect默认开启innodb_lock_wait_timeout可以设置锁等待超时时间。5.3 监控与优化工具当出现性能问题或锁争用时要知道如何排查查看当前锁信息-- 查看InnoDB锁状态和事务信息MySQL 5.7及以上 SELECT * FROM information_schema.INNODB_LOCKS; SELECT * FROM information_schema.INNODB_LOCK_WAITS; SELECT * FROM information_schema.INNODB_TRX\G -- \G 使结果垂直显示更易读INNODB_TRX表特别有用可以查看事务ID、状态、开始时间、正在执行的SQL等。查看进程列表SHOW PROCESSLIST;可以查看当前所有连接的状态发现处于Sleep、Locked或长时间Query的会话。分析慢查询日志长期未提交的事务可能隐藏在某个慢查询中。定期分析慢日志优化相关SQL。性能模式对于MySQL 5.6及以上版本Performance Schema提供了更强大的监控能力可以跟踪锁等待、阶段事件等。6. 从隔离级别到分布式事务的思考单机事务的隔离级别通过锁和MVCC尚能管理但一旦进入微服务、分库分表的分布式世界问题复杂度会指数级上升。这就是“分布式事务”的领域也是网络热词中“分布式事务一致性”、“Seata”、“RocketMQ事务消息”等话题火爆的原因。本地事务如MySQL事务保证的是单个数据库上的ACID。分布式事务则需要协调多个独立的资源管理器如不同的MySQL实例、消息队列等。CAP理论告诉我们在分布式系统中无法同时完美满足一致性、可用性和分区容错性。常见的分布式事务解决方案两阶段提交强一致但存在同步阻塞、协调者单点问题性能较差。TCC通过Try、Confirm、Cancel三个阶段由业务代码实现柔性事务的代表性能较好但业务侵入性强开发复杂。基于消息队列的最终一致性利用消息队列的可靠性实现数据的最终一致。这是目前互联网架构中最流行的模式之一。例如订单服务扣减库存后发送一个消息到MQ库存服务消费消息后再执行库存扣减。RocketMQ的事务消息就是为此场景设计的。Seata阿里开源的分布式事务解决方案提供了AT、TCC、Saga等多种模式对业务代码侵入较低是目前非常流行的选择。核心体会理解MySQL单机事务的隔离级别是理解更复杂的分布式事务问题的基础。分布式事务的本质是将单机数据库的隔离性、原子性等保障在网络不可靠、节点可能故障的分布式环境下通过一系列协议和妥协如最终一致性重新实现。当你为单机环境下“可重复读”和“读已提交”的选择而纠结时不妨想想在分布式场景下我们甚至常常需要主动放弃强一致性来换取可用性这能帮助你更好地把握技术选型的本质——权衡。