1. 事务到底在解决什么问题很多刚接触数据库的朋友会觉得事务这个概念有点虚好像平时写业务代码的时候也没怎么直接用到。但只要你稍微往深了想一层就会发现事务其实无处不在。你转账给别人你的余额扣了对方的余额加了这两件事必须同时成功或者同时失败否则账就对不上了。你在电商平台下单库存要减一订单要生成积分要累加这一连串操作要么全做完要么一个都别做不然系统数据就乱套了。事务要解决的核心问题就一个把多个独立的数据库操作打包成一个不可分割的整体。这个整体要么全部生效要么全部不生效没有中间状态。听起来简单但实现起来涉及的东西非常多这也是为什么事务一直是数据库领域最核心也最复杂的话题之一。我在实际工作中见过太多因为对事务理解不到位而踩坑的案例。有人以为开了事务就万事大吉结果因为隔离级别选错了导致出现幻读有人在一个事务里做了大量耗时操作把锁持有到天荒地老直接把线上系统拖垮还有人根本不知道事务的提交和回滚到底发生了什么出了问题完全不知道怎么排查。这些问题的根源都在于对事务的底层机制缺乏理解。这篇文章我会从实际使用的角度出发把MySQL事务的来龙去脉讲清楚。包括事务的四大特性到底是怎么实现的不同隔离级别分别解决了什么问题又带来了什么新问题MVCC这个核心机制是怎么运作的以及在实际项目中怎么用好事务。适合有一定MySQL使用经验、想深入理解事务底层原理的开发者也适合正在准备技术面试、需要系统梳理事务知识点的朋友。2. 事务的四大特性与底层实现逻辑2.1 原子性要么全做要么不做原子性是事务最基本的特性。一个事务里的所有操作要么全部执行成功要么全部不执行。不存在执行了一半的情况。这个特性听起来理所当然但实现起来并不简单。假设一个事务要执行三条SQL语句第一条执行完了第二条执行到一半数据库宕机了怎么办MySQL的做法是通过undo log来实现原子性。undo log记录的是数据修改之前的旧值当需要回滚的时候就用undo log里的旧值把数据恢复回去。我举个具体的例子。假设你执行了这样一组操作BEGIN; UPDATE account SET balance balance - 100 WHERE id 1; UPDATE account SET balance balance 100 WHERE id 2; COMMIT;如果第一条UPDATE执行完了第二条还没执行的时候系统崩溃了MySQL重启后会根据undo log把第一条UPDATE的修改撤销掉让balance恢复到原来的值。这样就保证了原子性。undo log的写入是跟数据修改一起进行的也就是说在修改数据之前会先把旧值写到undo log里。这个过程是在同一个事务上下文中完成的所以即使系统崩溃也能通过undo log来恢复。注意undo log本身也是要写磁盘的但它是逻辑日志记录的是“把id1的balance改回原来的值”这样的逻辑操作而不是物理层面的数据页变化。2.2 持久性提交了就不能丢持久性说的是一旦事务提交成功它对数据库的修改就是永久的即使之后系统崩溃了修改也不会丢失。这个特性的实现靠的是redo log。MySQL在修改数据的时候会先把修改操作写到redo log里然后再去修改内存中的数据页。注意这里修改的是内存中的Buffer Pool不是直接写磁盘。那为什么提交了就不会丢呢因为redo log在事务提交的时候会被刷到磁盘上这个由innodb_flush_log_at_trx_commit参数控制。这里有一个关键点需要理解数据页的修改和redo log的写入是两回事。数据页可能在内存里待很久才被刷到磁盘但只要redo log已经落盘了即使系统崩溃重启后也能通过redo log把数据页的修改重放出来。我画一个简单的流程帮助理解事务修改数据修改的是Buffer Pool里的数据页同时把修改操作写到redo log buffer事务提交时redo log buffer的内容根据配置刷到磁盘后台线程在合适的时机把Buffer Pool里的脏页刷到磁盘这个机制叫做WALWrite-Ahead Logging先写日志再写数据。为什么要这么做因为写日志是顺序写写数据页是随机写顺序写的性能远高于随机写。如果每次修改都直接写数据页性能会非常差。innodb_flush_log_at_trx_commit这个参数有三个值参数值含义安全性性能0提交时不刷盘由后台线程每秒刷一次可能丢1秒数据最高1每次提交都刷盘不丢数据最低2提交时写到OS缓存由OS决定何时刷盘系统崩溃可能丢数据中等生产环境一般建议设置为1除非你对性能有极高的要求并且能接受少量数据丢失的风险。2.3 隔离性并发事务互不干扰隔离性是说多个事务并发执行的时候一个事务的执行不应该被其他事务干扰。每个事务感觉就像在独占数据库一样。但完全的隔离性能太差了所以SQL标准定义了四种隔离级别让用户可以在隔离性和性能之间做取舍。这部分内容比较多我在下一节单独展开讲。2.4 一致性最终目标一致性是事务的最终目标它保证数据库从一个一致的状态转移到另一个一致的状态。比如转账前后两个账户的总金额应该是不变的。一致性其实是原子性、隔离性、持久性共同作用的结果再加上应用层面的约束比如外键约束、唯一索引等来共同保证的。数据库本身能做的是一部分应用代码的正确性也很重要。3. 四种隔离级别与并发问题详解3.1 三种并发问题在讲隔离级别之前先搞清楚并发事务可能带来的三种问题。脏读一个事务读到了另一个事务还没提交的数据。比如事务A把余额从100改成200但还没提交事务B读到了200。如果事务A回滚了事务B读到的就是脏数据。不可重复读同一个事务内两次读取同一行数据结果不一样。比如事务A第一次读余额是100此时事务B把余额改成200并提交了事务A再读就变成了200。同一个事务内两次读到的结果不一致。幻读同一个事务内两次执行同样的范围查询第二次查到了第一次没查到的行。比如事务A查询SELECT * FROM users WHERE age 20得到3条记录此时事务B插入了一条age25的记录并提交事务A再查就变成了4条。多出来的那条就像幻觉一样。这三种问题的严重程度是递增的脏读最严重读到的是完全不可信的数据不可重复读次之至少读到的数据是真实存在过的幻读最轻但也会影响业务逻辑的正确性。3.2 四种隔离级别的取舍SQL标准定义了四种隔离级别MySQL的InnoDB引擎都支持隔离级别脏读不可重复读幻读READ UNCOMMITTED可能可能可能READ COMMITTED不可能可能可能REPEATABLE READ不可能不可能InnoDB下不可能SERIALIZABLE不可能不可能不可能READ UNCOMMITTED基本没人用因为它连脏读都不防数据完全不可信。READ COMMITTED是很多数据库的默认级别比如Oracle、PostgreSQL它防止了脏读但可能出现不可重复读和幻读。在这个级别下每次SELECT都会生成一个新的ReadView所以能看到其他事务已经提交的最新数据。REPEATABLE READ是MySQL InnoDB的默认级别。它在事务开始时生成一个ReadView整个事务期间都用这个ReadView所以两次读到的数据是一样的。而且InnoDB通过Next-Key Lock间隙锁行锁在很大程度上解决了幻读问题。SERIALIZABLE是最严格的级别所有读操作都加共享锁写操作加排他锁事务完全串行执行。性能最差一般只在极少数对一致性要求极高的场景下使用。实操心得大部分互联网业务用REPEATABLE READ就够了。但如果你做的是金融类业务对数据一致性要求特别高可能需要考虑SERIALIZABLE或者至少在关键操作上手动加锁。3.3 怎么查看和设置隔离级别查看当前会话的隔离级别SELECT transaction_isolation;查看全局隔离级别SELECT global.transaction_isolation;设置当前会话的隔离级别SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;设置全局隔离级别需要重新连接才生效SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;也可以在配置文件中设置[mysqld] transaction-isolation READ-COMMITTED我个人的建议是如果你不确定用哪个就用默认的REPEATABLE READ。如果发现性能有问题再考虑降级到READ COMMITTED。但降级之前一定要确认业务逻辑能接受不可重复读和幻读。4. MVCC机制深度拆解4.1 MVCC是什么MVCC全称是Multi-Version Concurrency Control多版本并发控制。它是InnoDB实现隔离级别的核心机制核心思想是通过保存数据的多个版本让读操作和写操作互不阻塞。在没有MVCC的情况下如果一个事务正在修改某行数据另一个事务想读这行数据要么等待加锁要么读到不一致的数据。有了MVCC之后读操作可以读取数据的历史版本不需要等待写操作完成大大提高了并发性能。4.2 隐藏字段与版本链InnoDB的每行记录都有两个隐藏字段DB_TRX_ID最近修改这行记录的事务IDDB_ROLL_PTR回滚指针指向undo log中的上一个版本每次修改一行记录都会产生一个新的版本旧版本通过DB_ROLL_PTR串联起来形成一个版本链。版本链的头部是最新版本尾部是最旧的版本。假设有一行记录初始值是nameA事务ID为100。然后事务ID为200的事务把它改成了nameB事务ID为300的事务把它改成了nameC。版本链大概是这样当前记录: nameC, DB_TRX_ID300 ↓ DB_ROLL_PTR undo log: nameB, DB_TRX_ID200 ↓ DB_ROLL_PTR undo log: nameA, DB_TRX_ID1004.3 ReadView的可见性判断当一个事务要读取数据时InnoDB会根据ReadView来判断哪个版本对当前事务可见。ReadView主要包含以下信息m_ids生成ReadView时活跃的事务ID列表还没提交的事务min_trx_idm_ids中的最小值max_trx_id生成ReadView时系统应该分配给下一个事务的IDcreator_trx_id创建这个ReadView的事务ID判断一个版本是否可见的规则如果版本的DB_TRX_ID等于creator_trx_id说明是自己修改的可见如果DB_TRX_ID小于min_trx_id说明这个版本在ReadView创建之前就已经提交了可见如果DB_TRX_ID大于等于max_trx_id说明这个版本是在ReadView创建之后才产生的不可见如果DB_TRX_ID在min_trx_id和max_trx_id之间需要判断是否在m_ids中如果在说明事务还活跃不可见如果不在说明已提交可见如果当前版本不可见就沿着版本链往下找直到找到一个可见的版本。4.4 RC和RR的核心区别READ COMMITTED和REPEATABLE READ在MVCC层面的核心区别就是生成ReadView的时机不同READ COMMITTED每次SELECT都生成一个新的ReadView。所以每次读都能看到最新提交的数据。REPEATABLE READ只在第一次SELECT时生成ReadView整个事务期间复用这个ReadView。所以整个事务期间读到的数据是一致的。这就是为什么RC级别下会出现不可重复读而RR级别下不会。因为RC每次读都重新生成ReadView能看到其他事务新提交的数据RR始终用同一个ReadView看不到新提交的数据。注意RR级别下如果当前事务自己修改了数据那么后续的SELECT能看到自己的修改。因为判断规则第一条就是DB_TRX_ID等于creator_trx_id时可见。4.5 当前读与快照读MVCC只适用于快照读也就是普通的SELECT语句。对于当前读MVCC是不起作用的。当前读包括SELECT ... FOR UPDATESELECT ... LOCK IN SHARE MODEINSERT、UPDATE、DELETE操作当前读读取的是最新版本的数据并且会加锁。比如UPDATE操作它会先读取最新版本的数据然后加排他锁再执行修改。这里有一个容易混淆的点在RR级别下如果你先做了一次快照读然后另一个事务修改了数据并提交你再做当前读当前读会读到最新版本的数据。这算不算不可重复读严格来说算但这是当前读的语义决定的当前读就是要读最新的。5. 锁机制与幻读的解决5.1 InnoDB的锁类型InnoDB支持多种锁类型从不同维度可以有不同的分类。按锁的粒度分表锁锁整张表开销小但并发度低行锁锁单行记录开销大但并发度高按锁的模式分共享锁S锁允许其他事务读但不允许写排他锁X锁不允许其他事务读也不允许写按锁的算法分Record Lock锁单条记录Gap Lock锁一个范围但不包括记录本身Next-Key LockRecord Lock Gap Lock锁一个范围并包括记录本身5.2 间隙锁如何解决幻读幻读的问题是事务A查询某个范围事务B在这个范围内插入了新记录并提交事务A再查就多出了记录。InnoDB解决幻读的方式是在RR级别下使用Next-Key Lock。当事务A执行范围查询时不仅会锁住符合条件的记录还会锁住这些记录之间的间隙。这样事务B就无法在这个范围内插入新记录了。举个例子。假设表里有id为1、5、10三条记录事务A执行SELECT * FROM t WHERE id 3 AND id 8 FOR UPDATE;InnoDB会锁住(1, 5]和(5, 10]这两个区间。事务B想插入id6的记录会被阻塞因为6在(5, 10]这个区间内。实操心得间隙锁虽然解决了幻读但也带来了死锁的风险。两个事务如果以不同的顺序获取间隙锁就可能互相等待。所以在实际使用中尽量让事务以相同的顺序访问数据减少死锁概率。5.3 死锁的排查与预防死锁是并发事务中不可避免的问题。两个或多个事务互相持有对方需要的锁导致都无法继续执行。MySQL会自动检测死锁当检测到死锁时会回滚其中一个事务通常是持有锁最少的事务让另一个事务继续执行。被回滚的事务会收到一个错误ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction排查死锁的方法SHOW ENGINE INNODB STATUS;这个命令会输出最近一次死锁的详细信息包括涉及的事务、执行的SQL、持有的锁和等待的锁。通过分析这些信息可以找到死锁的原因。预防死锁的几个原则按固定顺序访问数据如果所有事务都按id升序访问就不会出现交叉等待缩短事务持有锁的时间事务里尽量只放必要的操作查询和业务逻辑放在事务外面使用较低的隔离级别RC级别下没有间隙锁死锁概率会低很多合理使用索引如果查询没有走索引会锁全表大大增加死锁概率6. 事务在实际项目中的使用要点6.1 事务的粒度控制事务的粒度是一个需要仔细权衡的问题。事务太大锁持有时间长并发性能差事务太小可能无法保证数据一致性。我见过一个典型的错误案例有人在事务里调用了外部接口接口响应时间不稳定有时候要好几秒。结果就是数据库锁被持有好几秒其他请求全部阻塞系统直接雪崩。正确的做法是事务里只放数据库操作而且尽量是必要的数据库操作。外部调用、文件IO、复杂计算这些都应该放在事务外面。// 错误做法 Transactional public void processOrder(Order order) { orderDao.insert(order); inventoryService.reduceStock(order.getProductId()); // 调用外部服务 paymentService.pay(order); // 调用外部服务 notificationService.send(order); // 调用外部服务 } // 正确做法 public void processOrder(Order order) { // 先做外部调用 paymentService.pay(order); // 再在事务里做数据库操作 transactionTemplate.execute(status - { orderDao.insert(order); inventoryService.reduceStock(order.getProductId()); return null; }); // 事务外做通知 notificationService.send(order); }6.2 长事务的危害与排查长事务是指执行时间很长的事务。长事务的危害包括锁持有时间长阻塞其他事务undo log无法及时清理导致版本链过长影响查询性能占用大量内存和磁盘空间排查长事务的方法SELECT * FROM information_schema.innodb_trx WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) 60;这个查询会找出执行时间超过60秒的事务。找到之后可以通过trx_mysql_thread_id找到对应的连接然后决定是kill掉还是等它执行完。KILL [connection_id];注意kill事务之前一定要确认这个事务在做什么不要贸然kill掉正在执行重要操作的事务。6.3 事务与索引的关系事务的锁是加在索引上的不是加在记录上的。这一点非常重要。如果一条SQL没有走索引InnoDB会锁住整张表的所有记录和间隙相当于锁表。这就是为什么OLTP系统里一定要避免没有索引的更新和删除操作。假设有一张用户表name字段没有索引。执行UPDATE users SET status 1 WHERE name test;这条SQL会锁住整张表因为InnoDB需要扫描所有记录来找到nametest的行。在扫描过程中所有记录都会被加上锁。如果name字段有索引InnoDB只需要锁住nametest对应的索引记录和对应的主键记录锁的范围小得多。6.4 事务的提交方式选择MySQL支持两种提交方式自动提交每条SQL都是一个独立的事务执行完自动提交显式事务用BEGIN或START TRANSACTION开启用COMMIT或ROLLBACK结束查看自动提交状态SELECT autocommit;大多数ORM框架比如MyBatis、Hibernate都会自动管理事务开发者只需要在Service层加一个Transactional注解就行。但要注意Transactional默认只在遇到RuntimeException时回滚如果抛的是Checked Exception不会回滚。需要显式指定Transactional(rollbackFor Exception.class)这个坑我踩过不止一次。有一次线上出了数据不一致的问题排查了半天才发现是因为抛了一个Checked Exception事务没有回滚。7. 常见问题速查与避坑指南7.1 事务不生效的常见原因问题现象可能原因解决方法加了Transactional但没回滚抛的是Checked Exception指定rollbackFor Exception.class加了Transactional但没回滚方法不是public的改为public方法加了Transactional但没回滚同类内部方法调用通过代理对象调用或拆分到不同类加了Transactional但没回滚数据库引擎不支持事务确认使用InnoDB引擎事务超时事务执行时间超过timeout设置优化SQL或调整timeout参数7.2 隔离级别选择速查业务场景推荐隔离级别理由一般互联网业务REPEATABLE READMySQL默认兼顾一致性和性能报表类查询READ COMMITTED不需要强一致性性能更好金融交易SERIALIZABLE或RR手动锁对一致性要求极高日志类写入READ COMMITTED并发写入性能更好7.3 实操避坑清单坑一在事务里做远程调用。远程调用的响应时间不可控会导致事务持有锁的时间不可控。解决方案是把远程调用移到事务外面。坑二大事务批量操作。一次性更新几万条数据会产生大量的undo log和redo log不仅执行慢还可能撑爆日志空间。解决方案是分批处理每批几百到几千条。坑三忘记设置rollbackFor。Spring的Transactional默认只回滚RuntimeExceptionChecked Exception不会触发回滚。解决方案是显式设置rollbackFor Exception.class。坑四RR级别下用SELECT ... FOR UPDATE导致间隙锁范围过大。如果WHERE条件没有走索引会锁住大量间隙严重影响并发。解决方案是确保FOR UPDATE的查询走索引。坑五事务里混合使用快照读和当前读。先快照读再当前读可能读到不一致的数据。解决方案是明确业务需求如果需要一致性读全部用快照读如果需要最新数据全部用当前读。坑六长事务导致undo log膨胀。长事务不提交undo log无法清理版本链越来越长查询需要遍历更多版本。解决方案是监控长事务及时处理。坑七主从复制延迟导致读到旧数据。事务提交后从库可能还没同步到最新数据。解决方案是强制走主库查询或者使用半同步复制。7.4 监控事务状态的常用命令-- 查看当前运行的事务 SELECT * FROM information_schema.innodb_trx\G -- 查看锁等待情况 SELECT * FROM information_schema.innodb_lock_waits\G -- 查看当前锁信息 SELECT * FROM information_schema.innodb_locks\G -- 查看事务隔离级别 SELECT transaction_isolation; -- 查看锁等待超时时间 SELECT innodb_lock_wait_timeout;innodb_lock_wait_timeout默认是50秒可以根据业务情况调整。如果业务对响应时间要求高可以调小一些比如10秒让等待锁的事务尽快失败而不是一直等。7.5 一个真实的生产案例之前遇到过一个线上问题某个接口偶尔会超时排查发现是一个更新操作被锁住了。通过SHOW ENGINE INNODB STATUS看到有一个事务持有了某行的排他锁很长时间没有释放。进一步排查发现那个事务里除了更新操作还有一个HTTP调用。HTTP调用的超时时间设置的是30秒也就是说如果HTTP调用超时事务会持有锁30秒。在这30秒内所有需要更新这行数据的请求都会被阻塞。解决方案很简单把HTTP调用移到事务外面。修改之后事务持有锁的时间从最长30秒降到了几毫秒接口超时问题彻底解决。这个案例告诉我们事务的边界一定要控制好。事务里只放必要的数据库操作任何可能耗时的操作都应该放在事务外面。8. 事务知识的延伸与进阶方向事务这块内容往深了挖还有很多可以聊的。比如分布式事务当你的系统拆分成多个微服务之后一个业务操作可能涉及多个数据库这时候单机事务就不够用了需要引入分布式事务方案。常见的分布式事务方案有2PC、TCC、Saga、本地消息表等每种方案都有自己的适用场景和优缺点。再比如MySQL 8.0对事务做了一些优化包括对只读事务的优化、对undo log的改进等。如果你用的是MySQL 8.0可以关注一下这些新特性。还有一个方向是事务与复制的结合。MySQL的主从复制是基于binlog的而binlog的写入时机和事务的提交时机是有关系的。理解这个关系对于排查主从一致性问题很有帮助。我个人在实际操作中的体会是事务这个东西光看文档是不够的一定要在真实环境里多试。开两个会话手动模拟各种并发场景观察锁的等待情况和数据的可见性这样理解才会深刻。遇到死锁不要慌用SHOW ENGINE INNODB STATUS看死锁日志分析清楚原因下次就能避免了。最后分享一个小技巧如果你不确定某个操作会不会加锁可以在测试环境开两个会话一个会话执行操作但不提交另一个会话尝试修改同一行数据看看会不会被阻塞。这个方法比看文档直观得多能帮你快速建立对锁的直觉。 
长河君 · 2026/10/21 0:28:52 · 阅读 1.2k MySQL事务与MVCC深度解析：隔离级别、锁机制与实战避坑指南
1. 事务到底在解决什么问题很多刚接触数据库的朋友会觉得事务这个概念有点虚好像平时写业务代码的时候也没怎么直接用到。但只要你稍微往深了想一层就会发现事务其实无处不在。你转账给别人你的余额扣了对方的余额加了这两件事必须同时成功或者同时失败否则账就对不上了。你在电商平台下单库存要减一订单要生成积分要累加这一连串操作要么全做完要么一个都别做不然系统数据就乱套了。事务要解决的核心问题就一个把多个独立的数据库操作打包成一个不可分割的整体。这个整体要么全部生效要么全部不生效没有中间状态。听起来简单但实现起来涉及的东西非常多这也是为什么事务一直是数据库领域最核心也最复杂的话题之一。我在实际工作中见过太多因为对事务理解不到位而踩坑的案例。有人以为开了事务就万事大吉结果因为隔离级别选错了导致出现幻读有人在一个事务里做了大量耗时操作把锁持有到天荒地老直接把线上系统拖垮还有人根本不知道事务的提交和回滚到底发生了什么出了问题完全不知道怎么排查。这些问题的根源都在于对事务的底层机制缺乏理解。这篇文章我会从实际使用的角度出发把MySQL事务的来龙去脉讲清楚。包括事务的四大特性到底是怎么实现的不同隔离级别分别解决了什么问题又带来了什么新问题MVCC这个核心机制是怎么运作的以及在实际项目中怎么用好事务。适合有一定MySQL使用经验、想深入理解事务底层原理的开发者也适合正在准备技术面试、需要系统梳理事务知识点的朋友。2. 事务的四大特性与底层实现逻辑2.1 原子性要么全做要么不做原子性是事务最基本的特性。一个事务里的所有操作要么全部执行成功要么全部不执行。不存在执行了一半的情况。这个特性听起来理所当然但实现起来并不简单。假设一个事务要执行三条SQL语句第一条执行完了第二条执行到一半数据库宕机了怎么办MySQL的做法是通过undo log来实现原子性。undo log记录的是数据修改之前的旧值当需要回滚的时候就用undo log里的旧值把数据恢复回去。我举个具体的例子。假设你执行了这样一组操作BEGIN; UPDATE account SET balance balance - 100 WHERE id 1; UPDATE account SET balance balance 100 WHERE id 2; COMMIT;如果第一条UPDATE执行完了第二条还没执行的时候系统崩溃了MySQL重启后会根据undo log把第一条UPDATE的修改撤销掉让balance恢复到原来的值。这样就保证了原子性。undo log的写入是跟数据修改一起进行的也就是说在修改数据之前会先把旧值写到undo log里。这个过程是在同一个事务上下文中完成的所以即使系统崩溃也能通过undo log来恢复。注意undo log本身也是要写磁盘的但它是逻辑日志记录的是“把id1的balance改回原来的值”这样的逻辑操作而不是物理层面的数据页变化。2.2 持久性提交了就不能丢持久性说的是一旦事务提交成功它对数据库的修改就是永久的即使之后系统崩溃了修改也不会丢失。这个特性的实现靠的是redo log。MySQL在修改数据的时候会先把修改操作写到redo log里然后再去修改内存中的数据页。注意这里修改的是内存中的Buffer Pool不是直接写磁盘。那为什么提交了就不会丢呢因为redo log在事务提交的时候会被刷到磁盘上这个由innodb_flush_log_at_trx_commit参数控制。这里有一个关键点需要理解数据页的修改和redo log的写入是两回事。数据页可能在内存里待很久才被刷到磁盘但只要redo log已经落盘了即使系统崩溃重启后也能通过redo log把数据页的修改重放出来。我画一个简单的流程帮助理解事务修改数据修改的是Buffer Pool里的数据页同时把修改操作写到redo log buffer事务提交时redo log buffer的内容根据配置刷到磁盘后台线程在合适的时机把Buffer Pool里的脏页刷到磁盘这个机制叫做WALWrite-Ahead Logging先写日志再写数据。为什么要这么做因为写日志是顺序写写数据页是随机写顺序写的性能远高于随机写。如果每次修改都直接写数据页性能会非常差。innodb_flush_log_at_trx_commit这个参数有三个值参数值含义安全性性能0提交时不刷盘由后台线程每秒刷一次可能丢1秒数据最高1每次提交都刷盘不丢数据最低2提交时写到OS缓存由OS决定何时刷盘系统崩溃可能丢数据中等生产环境一般建议设置为1除非你对性能有极高的要求并且能接受少量数据丢失的风险。2.3 隔离性并发事务互不干扰隔离性是说多个事务并发执行的时候一个事务的执行不应该被其他事务干扰。每个事务感觉就像在独占数据库一样。但完全的隔离性能太差了所以SQL标准定义了四种隔离级别让用户可以在隔离性和性能之间做取舍。这部分内容比较多我在下一节单独展开讲。2.4 一致性最终目标一致性是事务的最终目标它保证数据库从一个一致的状态转移到另一个一致的状态。比如转账前后两个账户的总金额应该是不变的。一致性其实是原子性、隔离性、持久性共同作用的结果再加上应用层面的约束比如外键约束、唯一索引等来共同保证的。数据库本身能做的是一部分应用代码的正确性也很重要。3. 四种隔离级别与并发问题详解3.1 三种并发问题在讲隔离级别之前先搞清楚并发事务可能带来的三种问题。脏读一个事务读到了另一个事务还没提交的数据。比如事务A把余额从100改成200但还没提交事务B读到了200。如果事务A回滚了事务B读到的就是脏数据。不可重复读同一个事务内两次读取同一行数据结果不一样。比如事务A第一次读余额是100此时事务B把余额改成200并提交了事务A再读就变成了200。同一个事务内两次读到的结果不一致。幻读同一个事务内两次执行同样的范围查询第二次查到了第一次没查到的行。比如事务A查询SELECT * FROM users WHERE age 20得到3条记录此时事务B插入了一条age25的记录并提交事务A再查就变成了4条。多出来的那条就像幻觉一样。这三种问题的严重程度是递增的脏读最严重读到的是完全不可信的数据不可重复读次之至少读到的数据是真实存在过的幻读最轻但也会影响业务逻辑的正确性。3.2 四种隔离级别的取舍SQL标准定义了四种隔离级别MySQL的InnoDB引擎都支持隔离级别脏读不可重复读幻读READ UNCOMMITTED可能可能可能READ COMMITTED不可能可能可能REPEATABLE READ不可能不可能InnoDB下不可能SERIALIZABLE不可能不可能不可能READ UNCOMMITTED基本没人用因为它连脏读都不防数据完全不可信。READ COMMITTED是很多数据库的默认级别比如Oracle、PostgreSQL它防止了脏读但可能出现不可重复读和幻读。在这个级别下每次SELECT都会生成一个新的ReadView所以能看到其他事务已经提交的最新数据。REPEATABLE READ是MySQL InnoDB的默认级别。它在事务开始时生成一个ReadView整个事务期间都用这个ReadView所以两次读到的数据是一样的。而且InnoDB通过Next-Key Lock间隙锁行锁在很大程度上解决了幻读问题。SERIALIZABLE是最严格的级别所有读操作都加共享锁写操作加排他锁事务完全串行执行。性能最差一般只在极少数对一致性要求极高的场景下使用。实操心得大部分互联网业务用REPEATABLE READ就够了。但如果你做的是金融类业务对数据一致性要求特别高可能需要考虑SERIALIZABLE或者至少在关键操作上手动加锁。3.3 怎么查看和设置隔离级别查看当前会话的隔离级别SELECT transaction_isolation;查看全局隔离级别SELECT global.transaction_isolation;设置当前会话的隔离级别SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;设置全局隔离级别需要重新连接才生效SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;也可以在配置文件中设置[mysqld] transaction-isolation READ-COMMITTED我个人的建议是如果你不确定用哪个就用默认的REPEATABLE READ。如果发现性能有问题再考虑降级到READ COMMITTED。但降级之前一定要确认业务逻辑能接受不可重复读和幻读。4. MVCC机制深度拆解4.1 MVCC是什么MVCC全称是Multi-Version Concurrency Control多版本并发控制。它是InnoDB实现隔离级别的核心机制核心思想是通过保存数据的多个版本让读操作和写操作互不阻塞。在没有MVCC的情况下如果一个事务正在修改某行数据另一个事务想读这行数据要么等待加锁要么读到不一致的数据。有了MVCC之后读操作可以读取数据的历史版本不需要等待写操作完成大大提高了并发性能。4.2 隐藏字段与版本链InnoDB的每行记录都有两个隐藏字段DB_TRX_ID最近修改这行记录的事务IDDB_ROLL_PTR回滚指针指向undo log中的上一个版本每次修改一行记录都会产生一个新的版本旧版本通过DB_ROLL_PTR串联起来形成一个版本链。版本链的头部是最新版本尾部是最旧的版本。假设有一行记录初始值是nameA事务ID为100。然后事务ID为200的事务把它改成了nameB事务ID为300的事务把它改成了nameC。版本链大概是这样当前记录: nameC, DB_TRX_ID300 ↓ DB_ROLL_PTR undo log: nameB, DB_TRX_ID200 ↓ DB_ROLL_PTR undo log: nameA, DB_TRX_ID1004.3 ReadView的可见性判断当一个事务要读取数据时InnoDB会根据ReadView来判断哪个版本对当前事务可见。ReadView主要包含以下信息m_ids生成ReadView时活跃的事务ID列表还没提交的事务min_trx_idm_ids中的最小值max_trx_id生成ReadView时系统应该分配给下一个事务的IDcreator_trx_id创建这个ReadView的事务ID判断一个版本是否可见的规则如果版本的DB_TRX_ID等于creator_trx_id说明是自己修改的可见如果DB_TRX_ID小于min_trx_id说明这个版本在ReadView创建之前就已经提交了可见如果DB_TRX_ID大于等于max_trx_id说明这个版本是在ReadView创建之后才产生的不可见如果DB_TRX_ID在min_trx_id和max_trx_id之间需要判断是否在m_ids中如果在说明事务还活跃不可见如果不在说明已提交可见如果当前版本不可见就沿着版本链往下找直到找到一个可见的版本。4.4 RC和RR的核心区别READ COMMITTED和REPEATABLE READ在MVCC层面的核心区别就是生成ReadView的时机不同READ COMMITTED每次SELECT都生成一个新的ReadView。所以每次读都能看到最新提交的数据。REPEATABLE READ只在第一次SELECT时生成ReadView整个事务期间复用这个ReadView。所以整个事务期间读到的数据是一致的。这就是为什么RC级别下会出现不可重复读而RR级别下不会。因为RC每次读都重新生成ReadView能看到其他事务新提交的数据RR始终用同一个ReadView看不到新提交的数据。注意RR级别下如果当前事务自己修改了数据那么后续的SELECT能看到自己的修改。因为判断规则第一条就是DB_TRX_ID等于creator_trx_id时可见。4.5 当前读与快照读MVCC只适用于快照读也就是普通的SELECT语句。对于当前读MVCC是不起作用的。当前读包括SELECT ... FOR UPDATESELECT ... LOCK IN SHARE MODEINSERT、UPDATE、DELETE操作当前读读取的是最新版本的数据并且会加锁。比如UPDATE操作它会先读取最新版本的数据然后加排他锁再执行修改。这里有一个容易混淆的点在RR级别下如果你先做了一次快照读然后另一个事务修改了数据并提交你再做当前读当前读会读到最新版本的数据。这算不算不可重复读严格来说算但这是当前读的语义决定的当前读就是要读最新的。5. 锁机制与幻读的解决5.1 InnoDB的锁类型InnoDB支持多种锁类型从不同维度可以有不同的分类。按锁的粒度分表锁锁整张表开销小但并发度低行锁锁单行记录开销大但并发度高按锁的模式分共享锁S锁允许其他事务读但不允许写排他锁X锁不允许其他事务读也不允许写按锁的算法分Record Lock锁单条记录Gap Lock锁一个范围但不包括记录本身Next-Key LockRecord Lock Gap Lock锁一个范围并包括记录本身5.2 间隙锁如何解决幻读幻读的问题是事务A查询某个范围事务B在这个范围内插入了新记录并提交事务A再查就多出了记录。InnoDB解决幻读的方式是在RR级别下使用Next-Key Lock。当事务A执行范围查询时不仅会锁住符合条件的记录还会锁住这些记录之间的间隙。这样事务B就无法在这个范围内插入新记录了。举个例子。假设表里有id为1、5、10三条记录事务A执行SELECT * FROM t WHERE id 3 AND id 8 FOR UPDATE;InnoDB会锁住(1, 5]和(5, 10]这两个区间。事务B想插入id6的记录会被阻塞因为6在(5, 10]这个区间内。实操心得间隙锁虽然解决了幻读但也带来了死锁的风险。两个事务如果以不同的顺序获取间隙锁就可能互相等待。所以在实际使用中尽量让事务以相同的顺序访问数据减少死锁概率。5.3 死锁的排查与预防死锁是并发事务中不可避免的问题。两个或多个事务互相持有对方需要的锁导致都无法继续执行。MySQL会自动检测死锁当检测到死锁时会回滚其中一个事务通常是持有锁最少的事务让另一个事务继续执行。被回滚的事务会收到一个错误ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction排查死锁的方法SHOW ENGINE INNODB STATUS;这个命令会输出最近一次死锁的详细信息包括涉及的事务、执行的SQL、持有的锁和等待的锁。通过分析这些信息可以找到死锁的原因。预防死锁的几个原则按固定顺序访问数据如果所有事务都按id升序访问就不会出现交叉等待缩短事务持有锁的时间事务里尽量只放必要的操作查询和业务逻辑放在事务外面使用较低的隔离级别RC级别下没有间隙锁死锁概率会低很多合理使用索引如果查询没有走索引会锁全表大大增加死锁概率6. 事务在实际项目中的使用要点6.1 事务的粒度控制事务的粒度是一个需要仔细权衡的问题。事务太大锁持有时间长并发性能差事务太小可能无法保证数据一致性。我见过一个典型的错误案例有人在事务里调用了外部接口接口响应时间不稳定有时候要好几秒。结果就是数据库锁被持有好几秒其他请求全部阻塞系统直接雪崩。正确的做法是事务里只放数据库操作而且尽量是必要的数据库操作。外部调用、文件IO、复杂计算这些都应该放在事务外面。// 错误做法 Transactional public void processOrder(Order order) { orderDao.insert(order); inventoryService.reduceStock(order.getProductId()); // 调用外部服务 paymentService.pay(order); // 调用外部服务 notificationService.send(order); // 调用外部服务 } // 正确做法 public void processOrder(Order order) { // 先做外部调用 paymentService.pay(order); // 再在事务里做数据库操作 transactionTemplate.execute(status - { orderDao.insert(order); inventoryService.reduceStock(order.getProductId()); return null; }); // 事务外做通知 notificationService.send(order); }6.2 长事务的危害与排查长事务是指执行时间很长的事务。长事务的危害包括锁持有时间长阻塞其他事务undo log无法及时清理导致版本链过长影响查询性能占用大量内存和磁盘空间排查长事务的方法SELECT * FROM information_schema.innodb_trx WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) 60;这个查询会找出执行时间超过60秒的事务。找到之后可以通过trx_mysql_thread_id找到对应的连接然后决定是kill掉还是等它执行完。KILL [connection_id];注意kill事务之前一定要确认这个事务在做什么不要贸然kill掉正在执行重要操作的事务。6.3 事务与索引的关系事务的锁是加在索引上的不是加在记录上的。这一点非常重要。如果一条SQL没有走索引InnoDB会锁住整张表的所有记录和间隙相当于锁表。这就是为什么OLTP系统里一定要避免没有索引的更新和删除操作。假设有一张用户表name字段没有索引。执行UPDATE users SET status 1 WHERE name test;这条SQL会锁住整张表因为InnoDB需要扫描所有记录来找到nametest的行。在扫描过程中所有记录都会被加上锁。如果name字段有索引InnoDB只需要锁住nametest对应的索引记录和对应的主键记录锁的范围小得多。6.4 事务的提交方式选择MySQL支持两种提交方式自动提交每条SQL都是一个独立的事务执行完自动提交显式事务用BEGIN或START TRANSACTION开启用COMMIT或ROLLBACK结束查看自动提交状态SELECT autocommit;大多数ORM框架比如MyBatis、Hibernate都会自动管理事务开发者只需要在Service层加一个Transactional注解就行。但要注意Transactional默认只在遇到RuntimeException时回滚如果抛的是Checked Exception不会回滚。需要显式指定Transactional(rollbackFor Exception.class)这个坑我踩过不止一次。有一次线上出了数据不一致的问题排查了半天才发现是因为抛了一个Checked Exception事务没有回滚。7. 常见问题速查与避坑指南7.1 事务不生效的常见原因问题现象可能原因解决方法加了Transactional但没回滚抛的是Checked Exception指定rollbackFor Exception.class加了Transactional但没回滚方法不是public的改为public方法加了Transactional但没回滚同类内部方法调用通过代理对象调用或拆分到不同类加了Transactional但没回滚数据库引擎不支持事务确认使用InnoDB引擎事务超时事务执行时间超过timeout设置优化SQL或调整timeout参数7.2 隔离级别选择速查业务场景推荐隔离级别理由一般互联网业务REPEATABLE READMySQL默认兼顾一致性和性能报表类查询READ COMMITTED不需要强一致性性能更好金融交易SERIALIZABLE或RR手动锁对一致性要求极高日志类写入READ COMMITTED并发写入性能更好7.3 实操避坑清单坑一在事务里做远程调用。远程调用的响应时间不可控会导致事务持有锁的时间不可控。解决方案是把远程调用移到事务外面。坑二大事务批量操作。一次性更新几万条数据会产生大量的undo log和redo log不仅执行慢还可能撑爆日志空间。解决方案是分批处理每批几百到几千条。坑三忘记设置rollbackFor。Spring的Transactional默认只回滚RuntimeExceptionChecked Exception不会触发回滚。解决方案是显式设置rollbackFor Exception.class。坑四RR级别下用SELECT ... FOR UPDATE导致间隙锁范围过大。如果WHERE条件没有走索引会锁住大量间隙严重影响并发。解决方案是确保FOR UPDATE的查询走索引。坑五事务里混合使用快照读和当前读。先快照读再当前读可能读到不一致的数据。解决方案是明确业务需求如果需要一致性读全部用快照读如果需要最新数据全部用当前读。坑六长事务导致undo log膨胀。长事务不提交undo log无法清理版本链越来越长查询需要遍历更多版本。解决方案是监控长事务及时处理。坑七主从复制延迟导致读到旧数据。事务提交后从库可能还没同步到最新数据。解决方案是强制走主库查询或者使用半同步复制。7.4 监控事务状态的常用命令-- 查看当前运行的事务 SELECT * FROM information_schema.innodb_trx\G -- 查看锁等待情况 SELECT * FROM information_schema.innodb_lock_waits\G -- 查看当前锁信息 SELECT * FROM information_schema.innodb_locks\G -- 查看事务隔离级别 SELECT transaction_isolation; -- 查看锁等待超时时间 SELECT innodb_lock_wait_timeout;innodb_lock_wait_timeout默认是50秒可以根据业务情况调整。如果业务对响应时间要求高可以调小一些比如10秒让等待锁的事务尽快失败而不是一直等。7.5 一个真实的生产案例之前遇到过一个线上问题某个接口偶尔会超时排查发现是一个更新操作被锁住了。通过SHOW ENGINE INNODB STATUS看到有一个事务持有了某行的排他锁很长时间没有释放。进一步排查发现那个事务里除了更新操作还有一个HTTP调用。HTTP调用的超时时间设置的是30秒也就是说如果HTTP调用超时事务会持有锁30秒。在这30秒内所有需要更新这行数据的请求都会被阻塞。解决方案很简单把HTTP调用移到事务外面。修改之后事务持有锁的时间从最长30秒降到了几毫秒接口超时问题彻底解决。这个案例告诉我们事务的边界一定要控制好。事务里只放必要的数据库操作任何可能耗时的操作都应该放在事务外面。8. 事务知识的延伸与进阶方向事务这块内容往深了挖还有很多可以聊的。比如分布式事务当你的系统拆分成多个微服务之后一个业务操作可能涉及多个数据库这时候单机事务就不够用了需要引入分布式事务方案。常见的分布式事务方案有2PC、TCC、Saga、本地消息表等每种方案都有自己的适用场景和优缺点。再比如MySQL 8.0对事务做了一些优化包括对只读事务的优化、对undo log的改进等。如果你用的是MySQL 8.0可以关注一下这些新特性。还有一个方向是事务与复制的结合。MySQL的主从复制是基于binlog的而binlog的写入时机和事务的提交时机是有关系的。理解这个关系对于排查主从一致性问题很有帮助。我个人在实际操作中的体会是事务这个东西光看文档是不够的一定要在真实环境里多试。开两个会话手动模拟各种并发场景观察锁的等待情况和数据的可见性这样理解才会深刻。遇到死锁不要慌用SHOW ENGINE INNODB STATUS看死锁日志分析清楚原因下次就能避免了。最后分享一个小技巧如果你不确定某个操作会不会加锁可以在测试环境开两个会话一个会话执行操作但不提交另一个会话尝试修改同一行数据看看会不会被阻塞。这个方法比看文档直观得多能帮你快速建立对锁的直觉。