MySQL事务底层原理与隔离级别、锁机制及死锁排查实战

客户系统上线那周我印象特别深。白天业务量不大一切正常结果晚上对账的时候发现订单表和库存表对不上了——有几笔订单扣了库存但订单记录没写进去。代码逻辑是同一个方法里先扣库存再生成订单怎么会出现只执行一半的情况后来查了半天发现是事务没生效方法内部 catch 了异常事务管理器感知不到又赶上 MyISAM 引擎本身不支持事务数据就停在中间状态了。那次踩坑之后我把 MySQL 事务的原理从头到尾梳理了一遍。说实话网上讲 ACID 和隔离级别的文章很多但大部分都停留在概念层面真正遇到问题的时候帮不上忙。这篇文章我想把事务的底层机制、并发控制、锁和日志的配合讲透再说说实际排查问题时的思路。适合刚从增删改查过渡到系统设计的开发者也适合被线上数据不一致问题折磨过的运维和后端同学。1. 事务不是什么先理清边界和适用场景很多人把事务理解成一组 SQL 要么全成功要么全失败这个说法不算错但它掩盖了更关键的问题——事务到底保护了什么又保护不了什么。1.1 事务解决的问题是并发而非故障单线程执行 SQL 的时候事务其实没什么存在感。就算你写了 BEGIN 和 COMMIT串行执行下数据也不会出问题。事务真正的价值体现在两个场景一是多个连接并发操作同一批数据二是执行过程中系统崩溃或报错需要把已经做了一半的改动撤销掉。拿电商下单来说用户 A 和用户 B 同时购买同一件库存只剩 1 件的商品。如果不用事务两个请求都读到库存 1都执行减 1最后库存变成 0但两个订单都成功了——超卖。这时候事务的隔离机制就起作用了第二个事务必须等第一个事务提交后才能读到新的库存值或者说它读到的快照里库存已经是 0就不会再执行扣减。但要注意事务不是万能的。它解决不了分布式场景下的数据一致性问题也解决不了因为业务逻辑写错导致的数据错误。比如你扣库存的 SQL 写成了UPDATE stock SET count count 1事务只会保证这个错误的加一操作要么成功要么回滚它不会帮你判断业务上到底该加还是该减。1.2 ACID 四个属性不是并列关系教科书喜欢把 ACID 四个属性并列讲但实际工程里它们是层层递进的关系。原子性Atomicity是说事务里的操作要么全做要么全不做这是靠 undo log 实现的一致性Consistency是说事务执行前后数据都要满足业务约束这是应用层的责任——数据库只保证从一个合法状态到另一个合法状态隔离性Isolation是说并发事务互不干扰靠锁和 MVCC 实现持久性Durability是说提交后数据不丢失靠 redo log 实现。我个人的理解是一致性是目标原子性、隔离性、持久性是手段。数据库通过原子性保证不留下中间状态通过隔离性保证并发操作不互相污染通过持久性保证崩溃后数据还能恢复三者合起来才能达到一致性。如果你看到某个系统说我们用了事务但数据还是乱了大概率是隔离级别设得太低或者事务范围没包住所有相关操作。1.3 哪些场景真的需要事务不是所有 SQL 都需要包在事务里。单条 UPDATE 或 DELETE 语句在 InnoDB 里本身就是原子操作不需要显式开事务。需要事务的是多条语句必须作为一个整体生效的场景比如转账扣款 加款、下单扣库存 生成订单 记录流水、复杂的级联更新。还有一种容易被忽略的场景先查后写。比如SELECT count(*) FROM t WHERE statuspending得到结果是 5然后业务逻辑根据这个 5 决定要不要插入一条新记录。这个读和写之间如果不在同一个事务里其他事务可能插入了一条新数据你的判断就过时了。这种问题在 REPEATABLE READ 隔离级别下可以通过事务内的连续读解决但如果读写分别在两个事务里就只能靠锁或者重新设计逻辑。注意把事务范围拉得越大越安全是常见的误区。长事务会占用大量 undo log 空间持有锁的时间也更长反而会把并发性能拖垮。事务应该短平快只包住必要的操作该提交就提交。2. 隔离级别与并发异常理论落到实操隔离级别是事务原理里概念最多、最容易混淆的部分。我先从大家最好理解的并发问题说起再讲 InnoDB 的四个隔离级别分别怎么处理这些问题。2.1 三种并发异常脏读、不可重复读、幻读假设有两个事务 T1 和 T2T1 做了修改但还没提交T2 读到了这笔未提交的数据然后 T1 回滚了——T2 就读到了一个不存在的数据。这叫脏读。脏读的本质是读取了事务的中间状态破坏了一致性。不可重复读发生在 T1 先读某一行数据T2 修改了这一行并提交T1 再次读同一行时发现值变了。注意关键在于同一行数据两次读取结果不一致。幻读更隐蔽T1 按某个条件查出一批记录比如statusvalid查出了 2 条T2 插入了一条新记录并提交T1 再次执行同样的查询发现变成了 3 条。幻读影响的是记录集合层面的变化不是单行数据的变化。这里有一个细节很多人搞混不可重复读和幻读的区别不只是改一行和多一行的区别。在没有行锁的情况下T2 修改 T1 读过的行的某列这算不可重复读T2 插入或删除记录导致 T1 的结果集变化这算幻读。处理方式也不同不可重复读靠锁住已读的行或靠 MVCC 的快照幻读靠间隙锁或 MVCC 的快照读。2.2 四个隔离级别一览MySQL InnoDB 支持四个隔离级别从上到下并发能力递减、一致性递增隔离级别脏读不可重复读幻读实现方式READ UNCOMMITTED可能可能可能直接读最新版本不加锁READ COMMITTED不可能可能可能每条语句生成新快照行锁REPEATABLE READ不可能不可能可能InnoDB 实际可避免事务开始生成快照行锁 间隙锁SERIALIZABLE不可能不可能不可能所有读都加锁相当于串行化注意一个关键点MySQL 的 InnoDB 引擎在 REPEATABLE READ 级别下通过间隙锁和 MVCC 实际上解决了幻读问题所以它的默认隔离级别就是 REPEATABLE READ。这和标准的 SQL 规范不完全一致——规范里 RR 是允许幻读的但 InnoDB 的实现超出了规范要求。2.3 实际开发中怎么选隔离级别很多团队直接把隔离级别改成 READ COMMITTED理由是并发性能好。这在某些场景下是对的比如报表查询、日志系统数据有一点偏差无所谓但性能要求高。但如果是金融、订单、库存这类强一致场景我建议保留默认的 REPEATABLE READ不要为了微小的性能提升牺牲一致性保障。曾经有同事为了提升并发把隔离级别改成 READ COMMITTED结果订单表中同一个用户的两个并发请求各自读到相同的账户余额都执行了扣款操作最后余额变成负数。排查了半天才发现是隔离级别改出来的问题——在 RC 级别下每次语句都会重新读最新已提交数据但两条语句之间没有间隙锁保护插入操作就会趁虚而入。改回 RR 之后问题消失。提示查看当前隔离级别用SELECT transaction_isolation;修改会话级隔离级别用SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;。实例级修改要改配置文件并在 [mysqld] 段加transaction-isolationREAD-COMMITTED改完要重启。线上环境改隔离级别一定要先在测试环境压测验证不要直接动。3. 事务的底层日志机制redo log 和 undo log 怎么配合事务的原子性和持久性靠的是两个日志undo log 负责回滚redo log 负责重做。这两个名字容易搞混我画个类比undo log 像 Photoshop 里的历史记录可以一步步撤销redo log 像 AutoSave 机制崩溃恢复时重放保存过的操作。3.1 redo log先写日志再写数据性能与安全的平衡点InnoDB 的数据是存在磁盘上的但如果每次提交事务都把数据页直接刷到磁盘性能会非常差。因为磁盘随机写太慢而数据页在内存中可能还没攒够一个完整的页就不得不落盘。redo log 解决的是这个问题提交事务时InnoDB 先把这一次的修改追加写到 redo log buffer然后按策略刷到磁盘上的 redo log 文件数据页本身可以留在内存缓冲池里等后续合适的时机再刷盘。这个机制叫 WALWrite-Ahead Logging核心思路就是日志先落盘数据后落盘。因为 redo log 是顺序写性能远高于随机写数据页所以这个设计大幅提高了事务提交的速度。如果事务提交后、数据页刷盘前数据库崩溃了重启时会根据 redo log 把已提交的事务重放一遍数据就回来了。你可能会问那未提交的事务写入 redo log 了吗会写但重放的时候有机制判断redo log 里的事务如果没记录 COMMIT 标记它会回滚掉而不是重放。InnoDB 通过 redo log 里的事务 ID 和状态标记来区分已提交和未提交的事务崩溃恢复时只应用已提交的事务未提交的直接丢弃。3.2 undo log回滚和 MVCC 的共同基础undo log 记录的是数据的反向操作。事务执行过程中如果修改了一行数据InnoDB 会同时生成一条 undo log记录修改前的值。回滚的时候只要逆着 undo log 把数据改回去就行。如果是 INSERTundo log 记录的是主键值如果是 UPDATE记录的是更新前的整行数据如果是 DELETE其实也是标记删除可以理解为反向 INSERT。除了回滚undo log 还是 MVCC 多版本链的基础。每一行数据上都会有一个隐藏列DB_ROLL_PTR指向 undo log 里的旧版本多个版本串成一条版本链。事务读取数据时根据自己可见的快照定位到对应的版本这就是读老版本的实现基础。这里有一个重要的实际经验长事务会导致 undo log 膨胀因为事务没提交之前它的 undo log 不能清理。如果有一个事务跑了几小时没提交它看到的旧版本数据就一直被保留undo log 文件可能涨到几十 GB占用大量磁盘空间还会影响后续事务读快照的性能。排查手段是information_schema.innodb_trx表里看长事务及时处理掉。3.3 binlog 和 redo log 的区别逻辑日志 vs 物理日志很多 DBA 面试都喜欢问 binlog 和 redo log 的区别。redo log 是 InnoDB 引擎层的物理日志记录的是某个数据页的某个偏移量被改成了什么值用于崩溃恢复循环写文件大小固定会覆盖旧内容。binlog 是 MySQL Server 层的逻辑日志记录的是执行了什么 SQL用于主从复制和数据恢复追加写不会覆盖。redo log 是在数据变更过程中实时产生的事务提交时就要保证 redo log 落盘binlog 是在事务提交时生成的记录的是最终执行结果。两者配合才能保证崩溃恢复时不丢数据、主从数据一致。两阶段提交2PC就是协调 binlog 和 redo log 提交的时序确保要么两个都成功要么都能回滚。注意很多开发者在本地开发时用sync_binlog0或innodb_flush_log_at_trx_commit0来提升性能这在开发环境没问题但生产环境必须设为 1。innodb_flush_log_at_trx_commit1表示每次事务提交都强制刷 redo log 到磁盘sync_binlog1表示每次提交 binlog 都 fsync 到磁盘。两个参数都设为 1 时最多丢失一个事务这是最安全的配置也是默认配置。4. MVCC 和锁机制隔离级别的实现基石隔离级别不是凭空存在的底层依赖两套机制MVCC多版本并发控制负责读操作不加锁也能读到一致性快照锁机制负责写操作之间的互斥以及当前读的一致性。4.1 MVCC 快照读读写不互斥的奥秘MVCC 的核心思想是一行数据在事务中修改时不是覆盖旧值而是生成一个新版本旧版本通过 undo log 保留。事务读取数据时不是读当前最新的值而是根据事务开始时间或语句开始时间生成一个可见版本视图从这个视图里找到自己应该看到的数据版本。在 REPEATABLE READ 级别下快照是在事务第一次执行 SELECT 时创建的之后整个事务内都复用这个快照所以同一事务内多次 SELECT 结果一致不受其他事务提交的影响。在 READ COMMITTED 级别下快照是每条语句开始前生成的所以同一事务内两次 SELECT 可能看到不同的已提交数据——这就是不可重复读的根源。理解这个机制后你就知道为什么 MVCC 让读不加锁普通 SELECT 是快照读读的是老版本不需要锁写操作INSERT/UPDATE/DELETE是当前读读的是最新版本需要加锁。读和写之间不互斥读不会被写阻塞写也不会被读阻塞只有在两个写操作竞争同一行时才会阻塞等待。这就是 InnoDB 在高并发下还能保持不错吞吐量的关键原因。4.2 当前读和行锁写操作怎么保证不冲突MVCC 解决了快照读的问题但如果是先查出来再决定改不改的操作就不能用快照读了。比如SELECT ... FOR UPDATE、UPDATE、DELETE它们必须读取最新已提交的数据然后基于这个数据做修改。这些操作走的是当前读会对涉及的行加锁。InnoDB 的行锁分成共享锁S 锁和排他锁X 锁。S 锁和 S 锁兼容多个事务可以同时对同一行加 S 锁做只读S 锁和 X 锁不兼容一个事务持 X 锁时其他事务既不能加 X 锁也不能加 S 锁。X 锁之间更不用说完全互斥。这个兼容性矩阵决定了并发场景下哪些操作能同时进行哪些必须排队。还有一点必须注意InnoDB 的行锁是通过索引实现的。如果 WHERE 条件里的列没有索引InnoDB 会退化为锁住所有扫描到的记录表面上看是锁整张表实际是锁了全表的所有行。这不仅是性能问题还可能造成意外的锁等待和死锁。排查时用EXPLAIN看执行计划确认是否走了索引这是优化锁问题的重要入口。4.3 间隙锁和 next-key lock怎么挡住幻读行锁只能锁住存在的行锁不住不存在的行。T1 查询statusvalid的记录某条记录不存在T2 插入一条statusvalid的新记录T1 再查就多了一条——这就是幻读。只靠行锁解决不了这个问题InnoDB 在 RR 级别下引入了间隙锁Gap Lock和 next-key lock。间隙锁锁的是索引记录之间的间隙比如索引值 1 和 5 之间有 2、3、4 的位置间隙锁会锁住这个范围防止其他事务在这个范围内插入新记录。next-key lock 是行锁 间隙锁的组合锁住记录本身 记录之前的间隙。这样 T1 执行范围查询并加锁时其他事务既不能修改已存在的记录也不能在间隙里插入新记录幻读就被挡在门外。间隙锁是 InnoDB 在 RR 级别下解决幻读的核心机制但也带来了额外的锁竞争。如果你确实不需要防止幻读把隔离级别降到 RC 就能减少间隙锁的竞争这是很多高并发团队的选择。不过要权衡好一致性需求不要因小失大。5. 死锁分析与排查现场实战死锁是事务并发下最常见也最棘手的故障之一。死锁的本质是两个事务各自持有一把锁同时又在等对方手里的锁谁都不让谁也走不了。InnoDB 内部有一个死锁检测机制会定期扫描锁等待图发现了就选一个代价最小的事务回滚掉释放它持有的锁让另一个事务继续执行。5.1 一个典型的死锁场景场景是这样的表accountid、balance事务 A 先执行UPDATE account SET balancebalance-100 WHERE id1;事务 B 同时执行UPDATE account SET balancebalance-100 WHERE id2;。然后事务 A 再执行UPDATE account SET balancebalance-100 WHERE id2;事务 B 再执行UPDATE account SET balancebalance-100 WHERE id1;。这就会出现经典循环等待A 持有 id1 的锁在等 id2 的锁B 持有 id2 的锁在等 id1 的锁。InnoDB 检测到这个环后会选择回滚其中一个事务另一个事务继续执行。你会在应用日志里看到Deadlock found when trying to get lock; try restarting transaction这样的报错。解决方法也简单让所有事务按照相同的顺序访问资源。比如先更新 id 小的记录再更新 id 大的记录这样两个事务都会先抢 id1 的锁谁先拿到谁就执行完不会出现互相等待的环。这个原则在批量更新、批量插入时格外重要——排序后再更新死锁概率大幅下降。5.2 排查死锁的现场手段线上遇到死锁报错第一件事不是改代码而是把现场数据捞出来分析。有两种途径一是查看 InnoDB 监控执行SHOW ENGINE INNODB STATUS里面会记录最近一次死锁的信息包括涉及的事务、锁、等待关系能帮你定位到具体是哪两条 SQL、哪两个事务纠缠在一起。二是开启死锁日志在配置文件里设置innodb_print_all_deadlocks1这样每次死锁都会记录到错误日志里多次死锁也能逐一分析。拿到日志后重点看四类信息事务 ID、当前执行的 SQL、持有锁的情况哪些 LOCK、等待锁的情况WAITING FOR THIS LOCK TO BE GRANTED。把这几个信息串起来基本就能还原死锁现场。如果死锁频发还可以在业务侧做重试机制——捕获死锁异常后随机延迟一点时间再重试整个事务大部分时候重试一次就能成功。5.3 降低死锁概率的实操建议死锁没法完全消除但可以从操作习惯上大幅降低概率。我总结了几条实际经验多个事务访问多张表或同一张表的多行时尽量按相同顺序操作。一次事务里尽量少执行 SQL缩短事务时长降低锁持有时间。避免在事务中做耗时操作比如远程调用、短信发送、大文件读写这些东西会拉长事务窗口增加锁竞争窗口。尽量减少锁定范围UPDATE和DELETE的 WHERE 条件尽量走索引避免全表锁。合理设置锁等待超时时间innodb_lock_wait_timeout默认 50 秒线上可以适当调小比如 10 秒避免事务卡死在锁等待上浪费资源。死锁并不可怕可怕的是对死锁的机制不理解全靠碰运气重试。理解了锁的兼容矩阵和事务的操作顺序大多数死锁问题都能在设计阶段规避掉。6. 事务参数的调优和监控让原理落地到运维理解了事务原理之后最后一步是把它落到日常运维里。InnoDB 提供了一些关键参数直接影响事务的持久性、性能和故障恢复时间这些参数值得每个后端开发者了解。6.1 关键参数速查表参数名默认值作用调优建议innodb_flush_log_at_trx_commit1事务提交时 redo log 是否刷盘0 每秒刷、1 每次刷、2 每秒刷但依赖 OS 缓存线上保持 1追求极限性能可改 2但可能丢 1 秒数据sync_binlog1binlog 写入策略1 每次 fsync线上保持 1可配合 binlog 组提交优化性能innodb_buffer_pool_size128MBInnoDB 缓存池大小决定数据页缓存在内存的量建议设为物理内存的 60%~80%但不是越大越好innodb_lock_wait_timeout50锁等待超时时间秒高并发场景可调小到 10~30避免长时间阻塞transaction_isolationREPEATABLE-READ默认隔离级别按业务一致性需求选择不要乱改innodb_rollback_on_timeoutOFF锁等待超时后是否回滚整个事务建议开启避免只回滚最后一条语句引发不一致这些参数里最核心的是innodb_flush_log_at_trx_commit和sync_binlog。它们的组合决定了崩盘时最多丢多少数据也决定了每次提交事务要等待多少次磁盘 fsync。如果你对数据安全要求极高比如订单系统、支付系统两个都保持 1 是最稳妥的。如果业务能容忍少量数据丢失比如日志系统、统计系统可以把innodb_flush_log_at_trx_commit降到 2性能会有明显提升因为不是每次提交都等磁盘刷盘而是每秒批量刷一次。6.2 用监控指标观察事务健康度运维事务光看参数不够还要盯着几个关键指标。SHOW GLOBAL STATUS LIKE Innodb_row_lock%能看行锁等待次数和等待时间information_schema.innodb_trx表能看当前活跃事务包括事务开始时间、状态、执行的 SQLperformance_schema里还有更细的事务等待事件。把这些指标配到监控系统里设置阈值告警比如行锁等待超过 5 秒、长时间未提交事务数大于 0就能及时发现问题。我遇到过一种情况数据库到深夜负载并不高但偶发超时。后来看到监控里有一个事务持续了几小时未提交它持有的锁把某个热门表的写入全堵了。虽然这个事务本身占用的 CPU 很少但锁等待阻塞了其他事务。这就是典型的隐形长事务不监控事务时长根本发现不了。6.3 快速定位慢事务的 SQLSQL 层面的排查也有一个实用技巧开启慢查询日志并设置long_query_time1然后从慢查询日志里看到哪些 SQL 执行时间长。如果慢 SQL 和锁等待密切相关执行SHOW ENGINE INNODB STATUS查看锁等待信息或者用performance_schema.events_statements_current查当前正在执行的事务 SQL。再分享一个排查技巧如果你怀疑某个事务卡在锁等待上可以执行SELECT * FROM sys.innodb_lock_waits;这条查询会直接告诉你谁在等谁的锁、等了多久、持锁事务执行了什么 SQL。这个视图在 MySQL 5.7 里默认支持排查锁问题时比手动分析INNODB STATUS快得多。注意不要在业务高峰期直接执行SHOW ENGINE INNODB STATUS它需要额外的内部处理可能短暂影响实例性能。建议在低峰期抓取或者用定时任务把输出落盘后再分析。7. 几条很实用的事务写作经验我前后处理过不少事务相关的问题从应用层的不生效到隔离级别配置错误再到死锁分析积累了一些零散但实用的经验趁这个机会一次性写出来。第一个经验测试事务是否生效最直接的办法不是看日志而是故意制造一个异常再验证。比如在事务里先 UPDATE 一行然后执行一个必然报错的 SQL最后检查那行数据有没有变。如果变了说明事务没生效要去查事务管理器配置、异常处理方式、数据库引擎类型。这个验证方法比任何文档都可靠。第二个经验写事务代码时尽量把事务控制在 service 层用声明式事务Transactional 这类注解或 XML 配置不要手动写 BEGIN/COMMIT/ROLLBACK。手动写的问题在于容易漏掉异常分支比如某个位置抛了异常但没走到 ROLLBACK数据就停在中间状态了。声明式事务帮你处理了这些边界情况开发者只需要关注业务逻辑。第三个经验看源码或者文档时不要只记结论。比如RR 级别能防幻读这个结论没问题但要搞清楚它依赖的是间隙锁还是 MVCC 快照读。不同场景下生效的机制不同排查问题时如果你只知道结论不知道原理很容易被表象误导。第四个经验所有事务相关的变更都先在测试环境压测再上生产。隔离级别、事务 timeout、事务内的锁等待时间这些参数在生产环境的真实负载下才会暴露问题。有些问题在测试环境数据量小、并发低根本压不出来。事务是 MySQL 最容易出问题也最值得深入研究的部分。把它彻底搞明白不仅能让你的代码更稳排查线上故障时也能省下大量时间。希望这篇文章能帮你在实际项目中少踩几个坑。