1. 先搞定基础认知MySQL事务到底解决什么问题1.1 从一个转账案例说起聊到MySQL逃不开事务这个话题。哪怕你是个刚入门写CRUD的选手面试时也大概率会被问“事务的ACID是什么”。但说实话背下来四个特性很简单真正理解事务在解决什么问题才是拉开差距的地方。我习惯用一个转账场景来开场A账户有1000块B账户有1000块现在A要转500给B。直觉上的操作是两步——先扣A的500再给B加500。如果第一步执行完数据库突然宕机了A的钱扣了B的钱没到账这500块就凭空消失了。这就是数据不一致。事务要解决的核心问题说白了就是一件事让多个操作要么全部成功要么全部失败不允许中间状态残留。把上面两步包进一个事务里要么都提交生效要么都回滚当作没发生这样数据就永远不会处于“扣了没到账”的尴尬状态。很多人觉得事务是数据库理所当然的功能其实不是。像早期的MyISAM存储引擎就没有事务能力后来InnoDB成为默认引擎事务才成了MySQL的标配。所以你现在用MySQL 5.7默认就是InnoDB事务默认就是开启的。1.2 ACID不是四个孤立的单词它们是一套逻辑链ACID四个特性很多教程是摊开来讲的但我的理解是它们之间存在因果关系**原子性Atomicity**是整个事务的地基。它保证了一个事务内的所有操作要么全部执行成功要么全部不执行。注意这里的关键词是“全部或不”这直接解决了上面转账场景的问题。原子性靠的是undo log事务执行过程中如果出错就用undo log里的记录把数据回滚到执行前的状态。**一致性Consistency**是事务的最终目标。它指的是事务执行前后的数据状态都必须是合法的、符合业务规则的。这个“业务规则”既包括数据库层面的约束如唯一键、非空、外键也包括业务代码里你自己定义的那些逻辑。原子性、隔离性、持久性本身都是在为一致性服务——如果原子性被破坏数据就会残留中间状态自然就不一致了如果隔离性没做好事务之间互相干扰也会破坏一致性如果持久性出问题宕机后数据丢失同样不一致。**隔离性Isolation**处理的是多个事务并发执行时的互相干扰问题。数据库是高并发的场景同一时刻肯定有多个事务在跑如果不做隔离一个事务可能读到另一个事务还没提交的数据。这个特性我们在下一节详细展开它是MySQL事务里最复杂、坑最多的地方。**持久性Durability**保证事务一旦提交结果就被永久保存下来。即使提交之后数据库立刻宕机数据也不会丢。这个靠的是redo log写入事务提交时会把变更记录到redo log日志文件里然后才去更新数据页。就算数据页没来得及刷盘重启后MySQL也会用redo log把数据恢复出来。这里我多说一句很多人容易混淆redo log和undo log——redo log记录的是“做了什么更改”用来崩溃恢复undo log记录的是“怎样撤销更改”用来回滚和一致性读。它们俩有本质区别面试官特别爱考。2. 隔离级别MySQL事务最核心也最容易踩坑的环节2.1 不隔离会出三种乱子既然事务要并发执行那就必须定义“事务之间互相能看到多少”。如果不做任何隔离会出现三种读异常从轻到重排列脏读Dirty Read事务A修改了一条数据还没提交事务B就去读读到了A修改后的“脏”数据。然后A回滚了B就把这个根本不存在的值拿去做后续操作了。这就像你看同事的草稿文档他写到一半说写错了删掉了你却把他删掉之前的内容引用进了自己的报告里。不可重复读Non-Repeatable Read事务A先读了一条数据得到值X然后事务B修改了这条数据并提交接着事务A再读同一条数据得到值YX不等于Y。在同一个事务里同一条数据读了两次结果不一样说明事务B的提交影响到了事务A的读操作。幻读Phantom Read事务A执行了一个范围查询比如查salary大于5000的所有员工得到5条记录。事务B插入了一条新的满足条件的记录并提交然后事务A再次执行同样的范围查询得到6条记录。多出来的那条就像“幻觉”一样。注意幻读和不可重复读的关键区别不可重复读是同一条记录的值变了幻读是一批记录的数量变了。这三种异常一个比一个严重数据库就用四种隔离级别来控制到底允许多少并发干扰发生。完整对照关系我整理成了表格方便面试前突击用隔离级别脏读不可重复读幻读READ UNCOMMITTED读未提交可能可能可能READ COMMITTED读已提交不可能可能可能REPEATABLE READ可重复读不可能不可能可能SERIALIZABLE串行化不可能不可能不可能2.2 四个隔离级别的实际对比不只看表还要看场景READ UNCOMMITTED基本属于“裸奔”状态事务能读到别人还没提交的数据。实际生产中几乎没人用这个级别因为脏读会带来非常离谱的问题——试想一个财务系统采用的数字本身都不可靠那计算结果还有什么意义。它唯一的用途大概是做性能极限压测的时候观察基线数据但正常开发我强烈不建议碰它。READ COMMITTED是很多其他数据库比如Oracle、PostgreSQL的默认隔离级别。它解决了脏读允许不可重复读。意思是事务A只能读到事务B提交后的数据所以不会读到“半成品”数据。但同一个事务里两次读同一条数据如果这期间别人提交了修改两次读到的值会不一样。这个级别在需要“每次读到的都是最新已提交数据”的场景下是有意义的比如实时报表统计。REPEATABLE READ是MySQL InnoDB的默认隔离级别。它解决了不可重复读也就是说在同一个事务里你反复读同一条数据值都是一样的。但按照标准定义它还有幻读问题——同一个事务两次范围查询结果集数量可能不一样。这里有个非常关键的坑MySQL的REPEATABLE READ级别下使用当前读SELECT ... FOR UPDATE、UPDATE、DELETE、INSERT配合间隙锁实际上已经把幻读问题也解决了。也就是说在MySQL里REPEATABLE READ的体验接近SERIALIZABLE但并发性能远高于SERIALIZABLE。这是InnoDB的一个隐藏福利也是面试官非常喜欢深挖的点——很多人只知道“RR会幻读”却不知道MySQL通过间隙锁做了额外处理。SERIALIZABLE是最高隔离级别直接让事务串行执行彻底杜绝所有并发干扰。但它也是最慢的相当于在所有人进数据库之前排个队一个事务执行完下一个才能开始。实际业务中几乎不会用这个级别因为它把并发能力降为零了除非你做的是极其敏感且低并发的场景。2.3 MySQL具体怎么实现这些隔离级别在InnoDB里隔离级别的实现主要靠两套机制锁和MVCCMulti-Version Concurrency Control多版本并发控制。锁机制的思路很朴素我读的时候不让你写我写的时候不让你读。但这会造成严重的并发阻塞性能很差。所以InnoDB引入了MVCC用“读写不互斥”的思路来优化读操作不阻塞写操作写操作也不阻塞读操作大家各读各的历史版本。MVCC的核心是每条数据在数据库里不止存一个版本而是通过undo log维护了多个历史版本。数据行上有两个隐藏字段trx_id最后一次修改这个行的事务ID和roll_pointer指向undo log里该行之前的版本。当一个事务执行快照读普通的SELECT就是快照读时它会根据事务启动时生成的read view活跃事务列表快照来判断哪些版本可见、哪些版本不可见。这样一来读操作永远读到的是一个一致性的快照不会受其他事务提交的影响。各种隔离级别的实现差异也很清晰READ UNCOMMITTED根本不去看read view直接读最新版本READ COMMITTED是每次SELECT都重新生成一个read view所以同一事务里两次读可能读到不同结果REPEATABLE READ是事务第一次执行SELECT时生成read view之后整个事务都用这一个视图所以不会被其他已提交事务干扰。这里插一个新手容易误解的点MVCC的read view只对快照读有效如果使用当前读比如SELECT ... FOR UPDATE、UPDATE、DELETEMVCC就不管了必须靠加锁来控制并发。这条规则在排查事务问题的时候特别重要很多人查了半天发现“明明隔离级别是RR怎么还会读到新数据”一查代码哦用了SELECT ... FOR UPDATE那自然不受MVCC保护。3. 事务并发与锁机制高并发下事务能不能扛住3.1 锁的分类再说细一点MySQL的锁分类从粒度、模式、算法三个维度看会清晰很多。从粒度上看锁分为表锁、行锁和页锁。InnoDB默认用的是行锁它是基于索引实现的——这就是为什么所有走不上索引的UPDATE操作会退化成锁全表这也是生产事故最常见的原因之一。我排查过很多次线上“突然所有更新卡住”的问题根源就是一条UPDATE语句的条件字段没有索引InnoDB在RR隔离级别下只能逐行扫描并给每行加锁效率极低且并发全卡。从模式上看行锁又分为共享锁S锁读锁和排他锁X锁写锁。共享锁之间可以共存共享锁和排他锁互斥排他锁和排他锁也互斥。直观理解读不阻塞读读写互相阻塞写和写更是互相阻塞。从算法上看就又回到了我们上文说的幻读问题——InnoDB用三种锁来解决记录锁Record Lock锁的是单个索引记录直接锁住那一条行。间隙锁Gap Lock锁的是一个范围但这个范围内没有任何具体记录。它锁的是索引记录之间的“空隙”。临键锁Next-Key Lock记录锁和间隙锁的组合锁住的是“一个范围 范围内的记录”。这是InnoDB在RR级别下的默认锁定算法范围查询时会用它来防止其他事务在这个区间插入新记录从而解决幻读。这里可以回到手机壳的概念想一想记录锁锁的是手机本身间隙锁锁的是手机和手机之间那个空位置临键锁则是把手机和它前面的空位一起锁住。这样别人想在空位置放新手机就放不进去幻读自然被堵死了。还有一个经常被忽略但实际非常重要的锁叫意向锁。它是表级别的锁分为意向共享锁和意向排他锁。这个锁的意义在于给某行加锁之前会先给表加上一个“意向锁”告诉其他事务“我这表里已经有人锁定行了你想锁整张表就得等一等”。没有意向锁的话行锁和表锁就会互相冲突数据库需要扫描每一行才能知道有没有行锁效率极低。意向锁让表锁的检查从O(N)变成了O(1)这是非常精巧的设计。3.2 死锁是怎么发生的怎么排查死锁的经典场景是事务A锁住了行1想锁行2事务B锁住了行2想锁行1。两个事务都在等对方释放锁谁也等不到就形成死锁了。我的标准排查流程是这样出现死锁报警后第一件事就是去MySQL里看最近一次死锁信息。数据库专门提供了命令SHOW ENGINE INNODB STATUS;这个命令的输出里有一段LATEST DETECTED DEADLOCK会打印出死锁发生的时间、两个事务各自执行到了哪条SQL、持有的锁和等待的锁分别是什么。结合应用日志里的业务ID基本可以在几分钟内定位到是哪两个业务路径互相抢锁了。定位之后最常见的缓解方法是调整两条SQL的执行顺序让所有事务都按照同一个顺序获取锁。比如订单模块的所有更新操作统一先更新订单主表、再更新订单明细表这样就永远不存在交叉等待的情况死锁概率大幅下降。另一个常用的兜底方案是设置锁等待超时时间-- 查看当前值 SHOW VARIABLES LIKE innodb_lock_wait_timeout; -- 设置锁等待超时单位是秒 SET GLOBAL innodb_lock_wait_timeout 10;锁等不到就不能一直等下去达到超时阈值后MySQL会让当前事务报错回滚至少不会无限期卡住业务。但要注意这个参数不宜设置得太小否则一些正常的业务高峰排队操作会被误杀我见过一些团队因为把这个调到3秒导致大促期间大量订单更新失败属于过犹不及。死锁还有一个很有意思的机制MySQL内部有死锁检测器默认开启。它会在事务等待锁的时候检测是否存在循环等待发现后就主动牺牲一个事务回滚它让另一个事务继续跑。所以实际上InnoDB并不会让你真的“卡死”而是牺牲较小代价的那一方。但被牺牲的事务需要应用层捕获异常、重试处理所以应用代码里对数据库唯一约束冲突、死锁回滚异常要有对应的兜底重试逻辑。3.3 结合热词看高并发事务的常规优化思路每次看到“mysql高并发解决方案”这个热搜词我就知道又有一批同学在并发和事务的交汇处卡住了。结合事务这个话题我给几个真正落地的优化方向。**第一减小事务范围。**事务越小持有的锁越少、时间越短并发自然越高。很多新手喜欢在一个事务里一口气做完所有数据库操作包括同步调用其他外部服务、做耗时的计算等。正确做法是外部调用和纯内存计算都不要放进事务里让事务保持“短、平、快”。**第二降低锁竞争。**同一个热点数据比如库存被大量事务同时更新行锁竞争会非常激烈。一种方案是把一行拆成多行比如库存表里把一个商品的库存拆成多个桶每次扣减随机选一个桶这样把对同一行的竞争分散到了多行上。另一种方案是引入异步削峰先把更新请求写入MQ由消费端以低并发慢慢更新库存把瞬时压力拉平。**第三合理利用Redis。**在读多写少的库存、商品场景可以用Redis做热点数据的预扣减数据库只负责最终的异步落账。当然这会引入最终一致性的问题需要自己设计补偿机制这是分布式事务的范畴了。4. 事务在代码里怎么落地注解用法与翻车现场4.1 事务注解背后的真实工作逻辑Java开发的同学对Transactional这个注解肯定不陌生。它用起来确实简单在方法上打一行注解就完事了。但它的底层逻辑其实是一个AOP切面方法执行前Spring帮你开启事务方法正常返回Spring帮你提交方法抛出未捕获的RuntimeExceptionSpring帮你回滚。这个注解上有几个关键属性真正理解的人不多。propagation属性控制事务的传播行为默认是REQUIRED意思是如果当前已经有事务就复用没有就新建。REQUIRES_NEW则是无论如何都新起一个独立事务常用于日志记录——主业务失败回滚但日志希望保留下来。isolation属性可以单独设置本方法的隔离级别默认跟随数据库。timeout属性控制事务超时时间超过就回滚rollbackFor则是用来处理受检异常的回滚问题默认情况下Spring只对RuntimeException回滚如果你在一个方法里捕获了Exception并自行吞掉事务是不会回滚的。这里我分享一个真实的生产事故。当时有个对账接口里面循环处理几千条数据代码大概是public void process(ListData list) { for (Data data : list) { try { updateData(data); } catch (Exception e) { log.error(单条处理失败, e); } } }process方法上虽然打了Transactional但由于异常被吞掉了事务感知不到任何异常所以永远不会回滚。更遭的是由于事务范围覆盖了整个循环任何一条数据失败虽然被catch住了但事务并没有回滚而是继续执行最终结果就是只有那一条失败前面的数据其实都已经写进库里了。这种方式并不可控而且如果循环中某条更新触发了死锁回滚会导致整个事务回滚连带之前成功的几千条也一起回滚掉。优化的方案是把循环放在事务外面、单条处理自己开小事务或者至少降低事务范围到“一批数据一个事务”。4.2 事务失效的六种场景面试和实战都会考事务失效是Spring事务里面最容易踩的坑我也是被坑过好几回才总结出这个清单。做一个速查表你直接保存就行失效场景根本原因解决办法Transactional加在非public方法上Spring AOP默认只代理public方法改成public方法同类内部方法调用this调用代理不生效直接走原方法注入自身代理或拆分到另一个Bean异常被catch住后吞掉Spring感知不到异常就不会回滚不吞异常或手动TransactionAopUtils.currentTransactionStatus().setRollbackOnly()抛出的是受检异常默认只对RuntimeException回滚用rollbackFor Exception.class数据库表引擎不是InnoDBMyISAM不支持事务换InnoDB配置了多数据源但切面没有走对事务管理器事务管理器配置不正确明确指定transactionManager其中第二条“同类内部方法调用”是隐蔽性最高的。Spring的声明式事务依赖AOP而AOP代理的机制要求你的方法必须通过代理对象调用才有效果。如果你在同一个类里写了一个方法A调用了另一个方法B这个调用走的是this指向的原对象完全没有经过代理B上的Transactional就变成了摆设。解决方案有两种一是给B方法单独拆到另一个Spring Bean里注入进来再调用二是在类里注入自己利用Autowired注入本类代理对象然后通过代理调用。第一种方案更清晰我一般推荐第一种。4.3 分布式事务订单与库存的经典一致性难题热度很高的“订单与库存分布式事务”这个话题本质上是单机事务能力不够用了之后的自然延伸。先说为什么单机事务解决不了。订单和库存往往分别在两个独立的数据库里甚至是两个微服务各自管一套库MySQL的单机事务只能保证同一个数据源内部的操作一致跨库操作在单体事务里是管不住的。传统的两阶段提交2PC在跨服务场景下存在同步阻塞问题——每个参与者都要等待协调者通知才能提交或回滚一旦协调者所在节点宕机所有人都卡住。目前业界更主流的是最终一致性方案典型代表是本地消息表和事务消息。以订单-库存场景举例下单时先在本地数据库写订单记录同时插入一条“扣减库存”的消息到本地消息表。这两个操作用本地事务保证原子性。然后有一个定时任务扫描本地消息表把没发送成功的消息投递到MQ库存服务消费MQ后执行扣减执行成功后回调通知订单服务更新消息状态。如果扣减失败MQ的重试机制会继续重试或者进入死信队列由人工介入处理。这套方案牺牲了强一致性换来的是高可用和高吞吐。业界还有个常被讨论的Saga模式把一个长事务拆成多个本地事务每个本地事务都有对应的补偿操作。订单失败了就去补偿逆向操作库存扣库存失败了就反向释放已扣的资源。关于分布式事务我有一条很务实的建议能靠业务设计规避的就别上分布式事务框架。比如很多场景用幂等键、状态机、对账机制就能解决问题非要引入Seata这类框架会带来额外的部署运维成本和性能损耗。我在实际项目中就见过有些订单状态流转不小心引入分布式事务后反而因为框架自身的协调开销把原本只有几十毫秒的接口拖到了几百毫秒。5. 常见问题与排查技巧实录5.1 我遇到过的高频事务问题做了这么多年MySQL排查总结几个出现频率最高的问题场景直接做成速查表现象排查方向快速解决事务执行到一半报“Lock wait timeout exceeded”查看information_schema.innodb_trx里是否有事务长期未提交杀掉长事务KILL TRX_ID对应的连接死锁报错“Deadlock found”执行SHOW ENGINE INNODB STATUS查死锁现场调整SQL执行顺序统一加锁顺序UPDATE卡住perf里全是等待检查是否有事务未提交看未提交事务的SQL联系对应开发处理事务没有回滚数据被污染确认代码里是否catch住了异常检查Transactional的rollbackFor配置多节点部署下重复出现的重复数据检查是否用了非幂等的写操作引入唯一索引或者幂等键5.2 几条实用排查命令排查事务问题时我最常用的几条SQL几乎形成了肌肉记忆分享给各位-- 查看当前所有正在运行的事务 SELECT * FROM information_schema.innodb_trx; -- 查看锁等待情况 SELECT * FROM performance_schema.data_lock_waits; -- 查看当前事务持有的锁 SELECT * FROM performance_schema.data_locks; -- 杀事务先找到trx_mysql_thread_id KILL trx_mysql_thread_id;实际排查时一般流程是先看innodb_trx里有没有执行时间特别长的事务比如trx_started显示是几小时以前的那基本可以断定是这个长事务持有了锁导致后续所有对该表的操作都在排队等锁。找到后联系业务方确认确实没有用的话直接KILL掉连接。有个小技巧值得分享查看innodb_trx时重点关注trx_rows_modified这个字段如果值很大说明它改了很多行还没提交这就意味着它持有大量行锁对其他事务的阻塞面非常广。5.3 实操中的几条独家心得第一条心得开发环境就要把事务问题暴露出来别等上线再查。我见过太多团队在开发库用Navicat手动提交导致事务长期不散到了生产环境一并发立刻原形毕露。建议项目从一开始就配置好性能监控把锁等待和死锁指标给到DBA和开发双端。第二条心得避免在事务里做外部调用RPC、HTTP、Redis写。道理很简单外部调用的耗时不可控如果那个外部服务变慢了你的事务就得一直开着、锁一直持有着直接影响当前表的所有并发操作。正确姿势是先更新数据库提交事务再发MQ或RPC通知配合对账任务来处理发送失败的情况。第三条心得SQL的条件列必须有索引这件事再怎么强调都不过分。一条UPDATE没走索引会升级成锁全表几个并发就直接把数据库打挂。排查时遇到事务相关的事故我第一步永远是看SQL的执行计划。养成写完条件查询就顺手EXPLAIN的习惯能帮你躲掉一半的线上事故。第四条心得关注autocommit的坑。MySQL默认是开启自动提交的也就是说在不显式BEGIN的情况下每一条SQL都会自动提交。问题出在这个设置会作用和连接绑定——如果你用连接池一个坑人的操作就是某处代码开启了事务却忘记提交连接归还到池子里后下一个人拿到这条连接时事务状态是脏的。虽然MyBatis等框架一般都会在逻辑前重置连接但排查问题时如果发现“奇怪的事务行为”可以先看看连接池的配置和连接状态。最后关于MySQL版本的提醒不同版本的MySQL在事务控制细节上是有差异的。比如MySQL 5.7对MVCC的处理和8.0有些微差别8.0还引入了一些新的锁机制比如不可见索引、备用事务相关参数等。写代码和排查问题时先看清版本别拿老经验硬套新环境。现在新项目我一般建议直接用8.0系毕竟8.0才是最活跃迭代的版本5.7已经步入维护尾声状态。
1. 先搞定基础认知MySQL事务到底解决什么问题1.1 从一个转账案例说起聊到MySQL逃不开事务这个话题。哪怕你是个刚入门写CRUD的选手面试时也大概率会被问“事务的ACID是什么”。但说实话背下来四个特性很简单真正理解事务在解决什么问题才是拉开差距的地方。我习惯用一个转账场景来开场A账户有1000块B账户有1000块现在A要转500给B。直觉上的操作是两步——先扣A的500再给B加500。如果第一步执行完数据库突然宕机了A的钱扣了B的钱没到账这500块就凭空消失了。这就是数据不一致。事务要解决的核心问题说白了就是一件事让多个操作要么全部成功要么全部失败不允许中间状态残留。把上面两步包进一个事务里要么都提交生效要么都回滚当作没发生这样数据就永远不会处于“扣了没到账”的尴尬状态。很多人觉得事务是数据库理所当然的功能其实不是。像早期的MyISAM存储引擎就没有事务能力后来InnoDB成为默认引擎事务才成了MySQL的标配。所以你现在用MySQL 5.7默认就是InnoDB事务默认就是开启的。1.2 ACID不是四个孤立的单词它们是一套逻辑链ACID四个特性很多教程是摊开来讲的但我的理解是它们之间存在因果关系**原子性Atomicity**是整个事务的地基。它保证了一个事务内的所有操作要么全部执行成功要么全部不执行。注意这里的关键词是“全部或不”这直接解决了上面转账场景的问题。原子性靠的是undo log事务执行过程中如果出错就用undo log里的记录把数据回滚到执行前的状态。**一致性Consistency**是事务的最终目标。它指的是事务执行前后的数据状态都必须是合法的、符合业务规则的。这个“业务规则”既包括数据库层面的约束如唯一键、非空、外键也包括业务代码里你自己定义的那些逻辑。原子性、隔离性、持久性本身都是在为一致性服务——如果原子性被破坏数据就会残留中间状态自然就不一致了如果隔离性没做好事务之间互相干扰也会破坏一致性如果持久性出问题宕机后数据丢失同样不一致。**隔离性Isolation**处理的是多个事务并发执行时的互相干扰问题。数据库是高并发的场景同一时刻肯定有多个事务在跑如果不做隔离一个事务可能读到另一个事务还没提交的数据。这个特性我们在下一节详细展开它是MySQL事务里最复杂、坑最多的地方。**持久性Durability**保证事务一旦提交结果就被永久保存下来。即使提交之后数据库立刻宕机数据也不会丢。这个靠的是redo log写入事务提交时会把变更记录到redo log日志文件里然后才去更新数据页。就算数据页没来得及刷盘重启后MySQL也会用redo log把数据恢复出来。这里我多说一句很多人容易混淆redo log和undo log——redo log记录的是“做了什么更改”用来崩溃恢复undo log记录的是“怎样撤销更改”用来回滚和一致性读。它们俩有本质区别面试官特别爱考。2. 隔离级别MySQL事务最核心也最容易踩坑的环节2.1 不隔离会出三种乱子既然事务要并发执行那就必须定义“事务之间互相能看到多少”。如果不做任何隔离会出现三种读异常从轻到重排列脏读Dirty Read事务A修改了一条数据还没提交事务B就去读读到了A修改后的“脏”数据。然后A回滚了B就把这个根本不存在的值拿去做后续操作了。这就像你看同事的草稿文档他写到一半说写错了删掉了你却把他删掉之前的内容引用进了自己的报告里。不可重复读Non-Repeatable Read事务A先读了一条数据得到值X然后事务B修改了这条数据并提交接着事务A再读同一条数据得到值YX不等于Y。在同一个事务里同一条数据读了两次结果不一样说明事务B的提交影响到了事务A的读操作。幻读Phantom Read事务A执行了一个范围查询比如查salary大于5000的所有员工得到5条记录。事务B插入了一条新的满足条件的记录并提交然后事务A再次执行同样的范围查询得到6条记录。多出来的那条就像“幻觉”一样。注意幻读和不可重复读的关键区别不可重复读是同一条记录的值变了幻读是一批记录的数量变了。这三种异常一个比一个严重数据库就用四种隔离级别来控制到底允许多少并发干扰发生。完整对照关系我整理成了表格方便面试前突击用隔离级别脏读不可重复读幻读READ UNCOMMITTED读未提交可能可能可能READ COMMITTED读已提交不可能可能可能REPEATABLE READ可重复读不可能不可能可能SERIALIZABLE串行化不可能不可能不可能2.2 四个隔离级别的实际对比不只看表还要看场景READ UNCOMMITTED基本属于“裸奔”状态事务能读到别人还没提交的数据。实际生产中几乎没人用这个级别因为脏读会带来非常离谱的问题——试想一个财务系统采用的数字本身都不可靠那计算结果还有什么意义。它唯一的用途大概是做性能极限压测的时候观察基线数据但正常开发我强烈不建议碰它。READ COMMITTED是很多其他数据库比如Oracle、PostgreSQL的默认隔离级别。它解决了脏读允许不可重复读。意思是事务A只能读到事务B提交后的数据所以不会读到“半成品”数据。但同一个事务里两次读同一条数据如果这期间别人提交了修改两次读到的值会不一样。这个级别在需要“每次读到的都是最新已提交数据”的场景下是有意义的比如实时报表统计。REPEATABLE READ是MySQL InnoDB的默认隔离级别。它解决了不可重复读也就是说在同一个事务里你反复读同一条数据值都是一样的。但按照标准定义它还有幻读问题——同一个事务两次范围查询结果集数量可能不一样。这里有个非常关键的坑MySQL的REPEATABLE READ级别下使用当前读SELECT ... FOR UPDATE、UPDATE、DELETE、INSERT配合间隙锁实际上已经把幻读问题也解决了。也就是说在MySQL里REPEATABLE READ的体验接近SERIALIZABLE但并发性能远高于SERIALIZABLE。这是InnoDB的一个隐藏福利也是面试官非常喜欢深挖的点——很多人只知道“RR会幻读”却不知道MySQL通过间隙锁做了额外处理。SERIALIZABLE是最高隔离级别直接让事务串行执行彻底杜绝所有并发干扰。但它也是最慢的相当于在所有人进数据库之前排个队一个事务执行完下一个才能开始。实际业务中几乎不会用这个级别因为它把并发能力降为零了除非你做的是极其敏感且低并发的场景。2.3 MySQL具体怎么实现这些隔离级别在InnoDB里隔离级别的实现主要靠两套机制锁和MVCCMulti-Version Concurrency Control多版本并发控制。锁机制的思路很朴素我读的时候不让你写我写的时候不让你读。但这会造成严重的并发阻塞性能很差。所以InnoDB引入了MVCC用“读写不互斥”的思路来优化读操作不阻塞写操作写操作也不阻塞读操作大家各读各的历史版本。MVCC的核心是每条数据在数据库里不止存一个版本而是通过undo log维护了多个历史版本。数据行上有两个隐藏字段trx_id最后一次修改这个行的事务ID和roll_pointer指向undo log里该行之前的版本。当一个事务执行快照读普通的SELECT就是快照读时它会根据事务启动时生成的read view活跃事务列表快照来判断哪些版本可见、哪些版本不可见。这样一来读操作永远读到的是一个一致性的快照不会受其他事务提交的影响。各种隔离级别的实现差异也很清晰READ UNCOMMITTED根本不去看read view直接读最新版本READ COMMITTED是每次SELECT都重新生成一个read view所以同一事务里两次读可能读到不同结果REPEATABLE READ是事务第一次执行SELECT时生成read view之后整个事务都用这一个视图所以不会被其他已提交事务干扰。这里插一个新手容易误解的点MVCC的read view只对快照读有效如果使用当前读比如SELECT ... FOR UPDATE、UPDATE、DELETEMVCC就不管了必须靠加锁来控制并发。这条规则在排查事务问题的时候特别重要很多人查了半天发现“明明隔离级别是RR怎么还会读到新数据”一查代码哦用了SELECT ... FOR UPDATE那自然不受MVCC保护。3. 事务并发与锁机制高并发下事务能不能扛住3.1 锁的分类再说细一点MySQL的锁分类从粒度、模式、算法三个维度看会清晰很多。从粒度上看锁分为表锁、行锁和页锁。InnoDB默认用的是行锁它是基于索引实现的——这就是为什么所有走不上索引的UPDATE操作会退化成锁全表这也是生产事故最常见的原因之一。我排查过很多次线上“突然所有更新卡住”的问题根源就是一条UPDATE语句的条件字段没有索引InnoDB在RR隔离级别下只能逐行扫描并给每行加锁效率极低且并发全卡。从模式上看行锁又分为共享锁S锁读锁和排他锁X锁写锁。共享锁之间可以共存共享锁和排他锁互斥排他锁和排他锁也互斥。直观理解读不阻塞读读写互相阻塞写和写更是互相阻塞。从算法上看就又回到了我们上文说的幻读问题——InnoDB用三种锁来解决记录锁Record Lock锁的是单个索引记录直接锁住那一条行。间隙锁Gap Lock锁的是一个范围但这个范围内没有任何具体记录。它锁的是索引记录之间的“空隙”。临键锁Next-Key Lock记录锁和间隙锁的组合锁住的是“一个范围 范围内的记录”。这是InnoDB在RR级别下的默认锁定算法范围查询时会用它来防止其他事务在这个区间插入新记录从而解决幻读。这里可以回到手机壳的概念想一想记录锁锁的是手机本身间隙锁锁的是手机和手机之间那个空位置临键锁则是把手机和它前面的空位一起锁住。这样别人想在空位置放新手机就放不进去幻读自然被堵死了。还有一个经常被忽略但实际非常重要的锁叫意向锁。它是表级别的锁分为意向共享锁和意向排他锁。这个锁的意义在于给某行加锁之前会先给表加上一个“意向锁”告诉其他事务“我这表里已经有人锁定行了你想锁整张表就得等一等”。没有意向锁的话行锁和表锁就会互相冲突数据库需要扫描每一行才能知道有没有行锁效率极低。意向锁让表锁的检查从O(N)变成了O(1)这是非常精巧的设计。3.2 死锁是怎么发生的怎么排查死锁的经典场景是事务A锁住了行1想锁行2事务B锁住了行2想锁行1。两个事务都在等对方释放锁谁也等不到就形成死锁了。我的标准排查流程是这样出现死锁报警后第一件事就是去MySQL里看最近一次死锁信息。数据库专门提供了命令SHOW ENGINE INNODB STATUS;这个命令的输出里有一段LATEST DETECTED DEADLOCK会打印出死锁发生的时间、两个事务各自执行到了哪条SQL、持有的锁和等待的锁分别是什么。结合应用日志里的业务ID基本可以在几分钟内定位到是哪两个业务路径互相抢锁了。定位之后最常见的缓解方法是调整两条SQL的执行顺序让所有事务都按照同一个顺序获取锁。比如订单模块的所有更新操作统一先更新订单主表、再更新订单明细表这样就永远不存在交叉等待的情况死锁概率大幅下降。另一个常用的兜底方案是设置锁等待超时时间-- 查看当前值 SHOW VARIABLES LIKE innodb_lock_wait_timeout; -- 设置锁等待超时单位是秒 SET GLOBAL innodb_lock_wait_timeout 10;锁等不到就不能一直等下去达到超时阈值后MySQL会让当前事务报错回滚至少不会无限期卡住业务。但要注意这个参数不宜设置得太小否则一些正常的业务高峰排队操作会被误杀我见过一些团队因为把这个调到3秒导致大促期间大量订单更新失败属于过犹不及。死锁还有一个很有意思的机制MySQL内部有死锁检测器默认开启。它会在事务等待锁的时候检测是否存在循环等待发现后就主动牺牲一个事务回滚它让另一个事务继续跑。所以实际上InnoDB并不会让你真的“卡死”而是牺牲较小代价的那一方。但被牺牲的事务需要应用层捕获异常、重试处理所以应用代码里对数据库唯一约束冲突、死锁回滚异常要有对应的兜底重试逻辑。3.3 结合热词看高并发事务的常规优化思路每次看到“mysql高并发解决方案”这个热搜词我就知道又有一批同学在并发和事务的交汇处卡住了。结合事务这个话题我给几个真正落地的优化方向。**第一减小事务范围。**事务越小持有的锁越少、时间越短并发自然越高。很多新手喜欢在一个事务里一口气做完所有数据库操作包括同步调用其他外部服务、做耗时的计算等。正确做法是外部调用和纯内存计算都不要放进事务里让事务保持“短、平、快”。**第二降低锁竞争。**同一个热点数据比如库存被大量事务同时更新行锁竞争会非常激烈。一种方案是把一行拆成多行比如库存表里把一个商品的库存拆成多个桶每次扣减随机选一个桶这样把对同一行的竞争分散到了多行上。另一种方案是引入异步削峰先把更新请求写入MQ由消费端以低并发慢慢更新库存把瞬时压力拉平。**第三合理利用Redis。**在读多写少的库存、商品场景可以用Redis做热点数据的预扣减数据库只负责最终的异步落账。当然这会引入最终一致性的问题需要自己设计补偿机制这是分布式事务的范畴了。4. 事务在代码里怎么落地注解用法与翻车现场4.1 事务注解背后的真实工作逻辑Java开发的同学对Transactional这个注解肯定不陌生。它用起来确实简单在方法上打一行注解就完事了。但它的底层逻辑其实是一个AOP切面方法执行前Spring帮你开启事务方法正常返回Spring帮你提交方法抛出未捕获的RuntimeExceptionSpring帮你回滚。这个注解上有几个关键属性真正理解的人不多。propagation属性控制事务的传播行为默认是REQUIRED意思是如果当前已经有事务就复用没有就新建。REQUIRES_NEW则是无论如何都新起一个独立事务常用于日志记录——主业务失败回滚但日志希望保留下来。isolation属性可以单独设置本方法的隔离级别默认跟随数据库。timeout属性控制事务超时时间超过就回滚rollbackFor则是用来处理受检异常的回滚问题默认情况下Spring只对RuntimeException回滚如果你在一个方法里捕获了Exception并自行吞掉事务是不会回滚的。这里我分享一个真实的生产事故。当时有个对账接口里面循环处理几千条数据代码大概是public void process(ListData list) { for (Data data : list) { try { updateData(data); } catch (Exception e) { log.error(单条处理失败, e); } } }process方法上虽然打了Transactional但由于异常被吞掉了事务感知不到任何异常所以永远不会回滚。更遭的是由于事务范围覆盖了整个循环任何一条数据失败虽然被catch住了但事务并没有回滚而是继续执行最终结果就是只有那一条失败前面的数据其实都已经写进库里了。这种方式并不可控而且如果循环中某条更新触发了死锁回滚会导致整个事务回滚连带之前成功的几千条也一起回滚掉。优化的方案是把循环放在事务外面、单条处理自己开小事务或者至少降低事务范围到“一批数据一个事务”。4.2 事务失效的六种场景面试和实战都会考事务失效是Spring事务里面最容易踩的坑我也是被坑过好几回才总结出这个清单。做一个速查表你直接保存就行失效场景根本原因解决办法Transactional加在非public方法上Spring AOP默认只代理public方法改成public方法同类内部方法调用this调用代理不生效直接走原方法注入自身代理或拆分到另一个Bean异常被catch住后吞掉Spring感知不到异常就不会回滚不吞异常或手动TransactionAopUtils.currentTransactionStatus().setRollbackOnly()抛出的是受检异常默认只对RuntimeException回滚用rollbackFor Exception.class数据库表引擎不是InnoDBMyISAM不支持事务换InnoDB配置了多数据源但切面没有走对事务管理器事务管理器配置不正确明确指定transactionManager其中第二条“同类内部方法调用”是隐蔽性最高的。Spring的声明式事务依赖AOP而AOP代理的机制要求你的方法必须通过代理对象调用才有效果。如果你在同一个类里写了一个方法A调用了另一个方法B这个调用走的是this指向的原对象完全没有经过代理B上的Transactional就变成了摆设。解决方案有两种一是给B方法单独拆到另一个Spring Bean里注入进来再调用二是在类里注入自己利用Autowired注入本类代理对象然后通过代理调用。第一种方案更清晰我一般推荐第一种。4.3 分布式事务订单与库存的经典一致性难题热度很高的“订单与库存分布式事务”这个话题本质上是单机事务能力不够用了之后的自然延伸。先说为什么单机事务解决不了。订单和库存往往分别在两个独立的数据库里甚至是两个微服务各自管一套库MySQL的单机事务只能保证同一个数据源内部的操作一致跨库操作在单体事务里是管不住的。传统的两阶段提交2PC在跨服务场景下存在同步阻塞问题——每个参与者都要等待协调者通知才能提交或回滚一旦协调者所在节点宕机所有人都卡住。目前业界更主流的是最终一致性方案典型代表是本地消息表和事务消息。以订单-库存场景举例下单时先在本地数据库写订单记录同时插入一条“扣减库存”的消息到本地消息表。这两个操作用本地事务保证原子性。然后有一个定时任务扫描本地消息表把没发送成功的消息投递到MQ库存服务消费MQ后执行扣减执行成功后回调通知订单服务更新消息状态。如果扣减失败MQ的重试机制会继续重试或者进入死信队列由人工介入处理。这套方案牺牲了强一致性换来的是高可用和高吞吐。业界还有个常被讨论的Saga模式把一个长事务拆成多个本地事务每个本地事务都有对应的补偿操作。订单失败了就去补偿逆向操作库存扣库存失败了就反向释放已扣的资源。关于分布式事务我有一条很务实的建议能靠业务设计规避的就别上分布式事务框架。比如很多场景用幂等键、状态机、对账机制就能解决问题非要引入Seata这类框架会带来额外的部署运维成本和性能损耗。我在实际项目中就见过有些订单状态流转不小心引入分布式事务后反而因为框架自身的协调开销把原本只有几十毫秒的接口拖到了几百毫秒。5. 常见问题与排查技巧实录5.1 我遇到过的高频事务问题做了这么多年MySQL排查总结几个出现频率最高的问题场景直接做成速查表现象排查方向快速解决事务执行到一半报“Lock wait timeout exceeded”查看information_schema.innodb_trx里是否有事务长期未提交杀掉长事务KILL TRX_ID对应的连接死锁报错“Deadlock found”执行SHOW ENGINE INNODB STATUS查死锁现场调整SQL执行顺序统一加锁顺序UPDATE卡住perf里全是等待检查是否有事务未提交看未提交事务的SQL联系对应开发处理事务没有回滚数据被污染确认代码里是否catch住了异常检查Transactional的rollbackFor配置多节点部署下重复出现的重复数据检查是否用了非幂等的写操作引入唯一索引或者幂等键5.2 几条实用排查命令排查事务问题时我最常用的几条SQL几乎形成了肌肉记忆分享给各位-- 查看当前所有正在运行的事务 SELECT * FROM information_schema.innodb_trx; -- 查看锁等待情况 SELECT * FROM performance_schema.data_lock_waits; -- 查看当前事务持有的锁 SELECT * FROM performance_schema.data_locks; -- 杀事务先找到trx_mysql_thread_id KILL trx_mysql_thread_id;实际排查时一般流程是先看innodb_trx里有没有执行时间特别长的事务比如trx_started显示是几小时以前的那基本可以断定是这个长事务持有了锁导致后续所有对该表的操作都在排队等锁。找到后联系业务方确认确实没有用的话直接KILL掉连接。有个小技巧值得分享查看innodb_trx时重点关注trx_rows_modified这个字段如果值很大说明它改了很多行还没提交这就意味着它持有大量行锁对其他事务的阻塞面非常广。5.3 实操中的几条独家心得第一条心得开发环境就要把事务问题暴露出来别等上线再查。我见过太多团队在开发库用Navicat手动提交导致事务长期不散到了生产环境一并发立刻原形毕露。建议项目从一开始就配置好性能监控把锁等待和死锁指标给到DBA和开发双端。第二条心得避免在事务里做外部调用RPC、HTTP、Redis写。道理很简单外部调用的耗时不可控如果那个外部服务变慢了你的事务就得一直开着、锁一直持有着直接影响当前表的所有并发操作。正确姿势是先更新数据库提交事务再发MQ或RPC通知配合对账任务来处理发送失败的情况。第三条心得SQL的条件列必须有索引这件事再怎么强调都不过分。一条UPDATE没走索引会升级成锁全表几个并发就直接把数据库打挂。排查时遇到事务相关的事故我第一步永远是看SQL的执行计划。养成写完条件查询就顺手EXPLAIN的习惯能帮你躲掉一半的线上事故。第四条心得关注autocommit的坑。MySQL默认是开启自动提交的也就是说在不显式BEGIN的情况下每一条SQL都会自动提交。问题出在这个设置会作用和连接绑定——如果你用连接池一个坑人的操作就是某处代码开启了事务却忘记提交连接归还到池子里后下一个人拿到这条连接时事务状态是脏的。虽然MyBatis等框架一般都会在逻辑前重置连接但排查问题时如果发现“奇怪的事务行为”可以先看看连接池的配置和连接状态。最后关于MySQL版本的提醒不同版本的MySQL在事务控制细节上是有差异的。比如MySQL 5.7对MVCC的处理和8.0有些微差别8.0还引入了一些新的锁机制比如不可见索引、备用事务相关参数等。写代码和排查问题时先看清版本别拿老经验硬套新环境。现在新项目我一般建议直接用8.0系毕竟8.0才是最活跃迭代的版本5.7已经步入维护尾声状态。
