作为一个在后端和数据架构领域摸爬滚打多年的从业者我越来越深刻地感受到一件事高并发系统里那些看似诡异的数据错乱、库存超卖、重复下单事故到最后排查原因往往都能归结到对事务隔离级别、锁机制和MVCC底层逻辑的理解不到位。很多人把“事务四大特性”“锁的粒度”背得滚瓜烂熟但真到了线上出问题——比如订单表明明有索引却还是锁住了全表、两个接口偶发性死锁、主从延迟后读到旧数据——就开始抓瞎。这篇文章不打算从《数据库原理》教材第一章讲起而是直接从实际发生过的故障和性能瓶颈切入把MySQL事务与锁在构建高并发数据系统时真正需要吃透的关键点掰开揉碎了讲清楚。适合正在做电商、支付、IM、库存系统这类强一致性业务的开发同学也适合刚入门但不想背死知识、想真正理解数据库底层行为的工程师。1. 从一次线上扣库存事故说起事务与锁到底在解决什么1.1 一次真实的超卖事故有次接手一个生鲜电商系统的优化工作线上反馈说“限时抢购时库存会变成负数”。代码逻辑看起来天衣无缝Transactional public boolean deductStock(Long skuId, Integer count) { // 1. 查询当前库存 Stock stock stockMapper.selectBySkuId(skuId); // 2. 校验库存是否充足 if (stock.getAvailable() count) { return false; } // 3. 扣减库存 stock.setAvailable(stock.getAvailable() - count); stockMapper.updateById(stock); return true; }这个代码在低并发下跑得飞快但一旦瞬间涌入大量请求问题就暴露了两个事务同时读到available10同时判断“105”成立然后都往库里面写最终结果变成了5而不是期望的0。这就是典型的并发事务相互干扰问题。事务A读到的数据、事务B读到的数据在各自事务提交之前都可能是不完整、不稳定的中间状态。所谓ACID其实核心就是在回答一个问题当大量事务同时操作同一批数据时系统凭什么保证最终结果是正确的1.2 事务的隔离性并不是“玄学”很多同学对ACID的A原子性、C一致性、I隔离性、D持久性都能说上一两句但落地到真实系统里最容易被忽视也最致命的是隔离性。隔离性并不是说“多个事务之间完全看不见对方”而是通过一套复杂的并发控制机制在“性能”和“正确性”之间做权衡。MySQL InnoDB引擎用一套组合拳来解决并发问题锁Locking通过独占资源来阻止并发操作同一行数据。MVCC多版本并发控制通过保存数据的多个版本来让读操作不阻塞写操作。事务日志Undo Log / Redo Log保证原子性和持久性同时为MVCC提供底层支持。这三者不是独立存在的而是协同工作的。理解它们之间的配合比单独背诵任何一个概念都有用得多。接下来我先从隔离级别入手因为这是事务机制的“总开关”。2. 隔离级别的取舍为什么MySQL默认用可重复读2.1 四种隔离级别与三个“读异常”SQL标准定义了四种隔离级别分别对应解决不同程度的数据一致性问题。我习惯用一个表格把它们的关系先列出来隔离级别脏读不可重复读幻读Read Uncommitted读未提交可能可能可能Read Committed读已提交不会可能可能Repeatable Read可重复读不会不会可能InnoDB已解决Serializable串行化不会不会不会脏读事务A修改了一条数据但还没提交事务B就读到了修改后的值。如果事务A回滚事务B读到的就是一个“根本不存在过”的数据。不可重复读事务A第一次读某行数据是10事务B把这行改成20并提交事务A第二次读就变成了20。同一事务内两次读同一行数据结果不一致。幻读事务A按某个条件查询第一次查到5条记录事务B插入了一条新纪录并提交事务A再次查询变成了6条。重点是新增了一条之前不存在的记录而不是某一行的值变了。读未提交和串行化基本属于两个极端前者太不安全后者性能太差。实际生产环境常见的只有两个选择Read Committed 和 Repeatable Read。2.2 MySQL为什么把默认值设为Repeatable ReadOracle、PostgreSQL这些数据库默认隔离级别是Read Committed但MySQL InnoDB的默认是Repeatable Read。这里有个关键点容易被误解MySQL的Repeatable Read通过间隙锁Gap Lock机制已经解决了幻读问题所以在这个级别下它实际上接近了SQL标准中Serializable的正确性但仍然保留了较高的并发性能。我自己的理解是MySQL当年选择RR作为默认既有历史兼容性的考虑MySQL 5.0之前的主从复制中binlog格式和隔离级别有绑定关系也有实际业务场景的考量——很多金融、订单类业务天然需要在一个事务里重复读取同一批数据并保证结果一致。2.3 实际项目中如何选择隔离级别实践里我的建议比较直接默认使用RRMySQL默认但必须理解其底层原理不要盲目修改。如果业务对“深度一致性”要求不高、且主要做读多写少的报表分析类系统可以考虑改成Read Committed来减少间隙锁带来的锁竞争。我经历过的几个高并发订单系统最终都保留RR但把很多业务逻辑拆成了“先快照读再当前读”的模式。原因是RR下的快照读天然具备一致性非锁定读的特性对报表、统计类查询非常友好。一个非常反直觉的坑是RR级别下如果先做了一次快照读普通SELECT后来在同一事务里做当前读SELECT FOR UPDATE或者UPDATEMySQL会使用当前读的版本这可能导致数据显示“异常前后不一致”很多初学者在这里栽过跟头。3. 锁的分类与兼容性全局锁、表锁、行锁与意向锁3.1 锁粒度决定并发上限InnoDB支持三种粒度的锁全局锁锁整个实例通常用于全库备份。FLUSH TABLES WITH READ LOCK 会阻塞所有写操作。除非做物理备份否则线上环境基本不建议用。表锁锁定整个表InnoDB在DDL操作或者某些特殊场景下会使用但也提供了LOCK TABLES命令手动加锁。行锁InnoDB真正强大的地方锁定的粒度是索引记录。只有通过索引条件检索数据时InnoDB才会使用行锁否则会升级为表锁这是一个经典的坑后面重点说。从并发性能来说行锁 表锁 全局锁。锁粒度越细并发度越高但锁管理的代价也越大。InnoDB的行锁是通过给索引项加锁实现的所以行锁必须有索引作为前提且索引要能让执行计划精准定位到记录。3.2 意向锁与锁兼容矩阵有一类锁容易被人忽略意向锁Intention Lock。它其实是个“标记”性质的锁核心目的是让表锁和行锁之间快速判断是否有冲突避免每次要加表锁时扫描全表的行锁。这玩意儿有点像你进会议室之前在门口白板上写字“里面有人”后来的人不用推门看看白板就知道这间会议室现在能不能进。意向锁分两种意向共享锁IS锁事务打算给某些行加共享锁。意向排他锁IX锁事务打算给某些行加排他锁。InnoDB的锁兼容矩阵如下锁类型共享锁S排他锁X意向共享锁IS意向排他锁IX共享锁S兼容冲突兼容冲突排他锁X冲突冲突冲突冲突意向共享锁IS兼容冲突兼容兼容意向排他锁IX冲突冲突兼容兼容记这个表不用死背只需要掌握一条底层逻辑任何锁之间只有“读读”是兼容的“读写”和“写写”都必须互斥。意向锁本身没有改变行锁之间的兼容关系它的存在只是为了快速判断表级锁是否与已有行锁冲突。3.3 悲观锁与乐观锁两种截然不同的并发控制思路切入到业务代码层面锁还可以分为悲观锁和乐观锁这个也是BAT面试的高频考点。悲观锁的逻辑是“我悲观地认为并发冲突一定会发生”所以先拿锁再干活。最典型的实现就是SELECT ... FOR UPDATE。这种做法的优点是绝对安全缺点是锁等待会拖垮吞吐量。-- 事务A BEGIN; SELECT * FROM stock WHERE sku_id 1001 FOR UPDATE; -- 假设查询到库存为10 UPDATE stock SET available available - 5 WHERE sku_id 1001; COMMIT;在上面的SQL中事务A执行的第一条SELECT FOR UPDATE会把sku_id1001这行锁住事务B如果也执行同样的语句会一直阻塞直到A提交。在没有索引的情况下这句会在全表加锁切记。乐观锁的逻辑是“我乐观地认为并发冲突不常见”所以不先拿锁而是在更新时检查版本号或状态是否发生了变化。典型实现UPDATE stock SET available available - 5, version version 1 WHERE sku_id 1001 AND version 10; -- 如果影响行数为0说明版本已变化需要重试这里最核心的技术点是UPDATE语句本身在InnoDB中就是一个排他锁操作即使你不用SELECT FOR UPDATE引擎也会对命中行加X锁。乐观锁的关键在于通过WHERE条件让冲突的更新“自动失效”更准确的说法是它在应用层做并发控制数据库层只是正常执行单行更新。我的经验是秒杀、抢购这类“写入并发极高”的场景乐观锁重试机制往往好用而账务操作、库存预占这类“冲突概率高且不容失败”的场景悲观锁反而更可控因为重试的代价可能比等待锁更昂贵。4. MVCC的底层逻辑快照读与当前读4.1 一条记录的版本链是怎么生成的很多人以为MVCC就是简单的“读写分离”其实底层靠的是Undo Log版本链和Read View机制。每次对记录进行修改InnoDB不会直接覆盖旧数据而是将旧数据放入Undo Log中新数据生成一个新的版本号事务ID版本之间通过指针串成一条链。所有版本构成一个链表最新版本在链表的头部。举个例子-- 初始版本基于事务T1插入值为100 INSERT INTO account(id, balance) VALUES(1, 100); -- 事务T2修改余额变为200 UPDATE account SET balance 200 WHERE id 1;此时这条记录上有两个版本V1(balance100, 事务T1创建)V2(balance200, 事务T2创建)V2的roll_pointer指向V1。如果事务T3又改了余额变成300就会生成V3并指向V2。4.2 Read View的可见性判断规则当事务执行快照读时InnoDB会生成一个Read View里面记录了几个关键信息m_ids生成Read View时当前活跃未提交事务的ID列表。min_trx_idm_ids中最小的活跃事务ID。max_trx_id生成Read View时InnoDB分配的下一个事务ID也就是当前系统之内未来可能产生的事务ID的上限。creator_trx_id生成Read View的事务自己的ID。判断一条记录的某个版本是否可见规则是这样的如果被访问版本的trx_id creator_trx_id自己改的当然能看见。如果被访问版本的trx_id min_trx_id说明该版本在Read View生成前就已经提交可见。如果被访问版本的trx_id max_trx_id说明该版本是由未来事务生成的不可见。如果min_trx_id trx_id max_trx_id需要判断trx_id是否在m_ids中如果在说明还活跃未提交不可见如果不在已经提交可见。这个判断逻辑每访问一条记录的每个版本都要执行一遍如果版本链很长性能损耗很明显。这也是为什么我一直劝别人别在大表上频繁做长事务——版本链太长会导致快照读变慢。4.3 快照读与当前读的本质差异快照读Snapshot Read普通的SELECT语句。读取的是记录在某个时间点的快照版本不需要加锁所以不会阻塞其他事务的写操作。这就是“读不阻塞写”的底层原因。当前读Current ReadSELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE这些操作读到的是记录的最新版本并且必须加锁。这就是“写阻塞写”的原因。为什么UPDATE不能走快照读因为如果更新基于旧版本会导致覆盖更新。永远记住这个公式当前读 最新版本 锁保护。在RR隔离级别下同一个事务里多次快照读会复用同一个Read View这就是可重复读的实现。在Read Committed级别下每次快照读都会生成新的Read View所以会出现不可重复读的问题。5. 高并发系统的性能杀手大事务、长持有锁与索引失效5.1 大事务引发的Undo Log膨胀与主从延迟事务的大小直接影响MySQL的整体性能。一个事务操作了10万行回滚段里的Undo Log就会非常庞大占用的磁盘和内存资源随之暴涨。更麻烦的是事务提交后Undo Log还不能立即清理因为可能有其他事务的Read View还在引用这些旧版本。如果一直有长查询存活Undo Log就会被长期保留这就是很多人线上“磁盘空间莫名其妙暴涨”的幕后推手之一。我处理过一个典型案例某财务系统每天凌晨批量跑对账事务单条事务最多处理超过50万条记录运行期间主库磁盘使用率飙升到90%以上从库延迟从秒级变成小时级最后整个报表链路全部阻塞。那种感觉就像一个人一次性吃了一周的饭消化系统直接瘫了。解决办法把大事务拆成小事务。最简单有效的方式是分批提交比如每500条或每1000条一个事务。虽然事务数量变多了但每个事务的持有锁时间极短Undo Log也小整体系统反而更稳。5.2 “行锁变表锁”的经典陷阱与排查方法InnoDB的行锁依赖于索引。如果条件列没有索引数据库就只能全表扫描然后把所有扫描到的记录都锁住——这在效果上等于表锁。有个血的教训一张订单明细表原来在order_id上有索引后面为了某个查询需求新加了一个字段但没建索引。某次运营活动按新字段做批量更新一条UPDATE语句直接把整张表锁住十几个小时所有订单操作全部阻塞线上报警电话被打爆。检查是否有索引其实非常快SHOW INDEX FROM order_detail; EXPLAIN SELECT * FROM order_detail WHERE user_phone 13800138000;EXPLAIN里看到typeALL或者rows预估很高就要警惕了。经验法则UPDATE和DELETE的WHERE条件必须命中索引哪怕是一个选择性不高的索引也好过全表扫描加锁。5.3 锁等待超时与参数调优高并发下最头疼的问题之一就是锁等待。MySQL默认的锁等待时间是50秒SHOW VARIABLES LIKE innodb_lock_wait_timeout;设成50秒的本意是给大事务留足时间但实际在高并发场景下50秒的锁等待会让所有线程都堆死在那里连接池被打满整个服务雪崩。我的做法是根据业务接口的RT要求调整这个值。比如订单扣库存的接口要求200ms内返回那锁等待就配成3秒左右超过时间直接报错让上层走重试或降级。与其傻等不如快速失败把错误暴露出来让链路快速切换。SET GLOBAL innodb_lock_wait_timeout 3; SET SESSION innodb_lock_wait_timeout 3;注意这两条命令的作用范围不一样全局设置不会影响已经存在的连接需要新连接才会生效。还有一个关键参数是innodb_lock_wait_timeout和死锁检测的配合。如果开了死锁检测默认开启事务发生死锁时MySQL会主动回滚一个事务表面上表现为报错“Deadlock found when trying to get lock”实际的处理逻辑是快速牺牲一个事务来换取系统继续运行。6. 死锁排查链路从告警到最终修复的实操记录6.1 死锁的必要条件与InnoDB的处理策略死锁说白了就是两个或多个事务各自持有一把锁同时等待对方释放自己需要的锁。理论上死锁需要四个条件互斥、持有并等待、不可剥夺、循环等待。InnoDB处理死锁的策略很简单牺牲一个事务回滚它释放它持有的所有锁让其他事务继续执行。被牺牲的事务会收到一条错误提示通常是ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction这意味着应用层必须有重试机制。没有重试机制的死锁处理等于没处理。6.2 定位死锁的完整排查SQL每次遇到死锁告警我先做的不是猜而是把现场情况捞出来。最重要的命令SHOW ENGINE INNODB STATUS;这个命令会输出LATEST DETECTED DEADLOCK一栏里面详细记录了死锁发生时的两条事务各自执行到了哪条SQL、持有什么锁、等待什么锁。再看TRANSACTIONS一节找到当前所有活跃事务的等待状态。为了让排查更精准我通常还会查询SELECT * FROM information_schema.INNODB_TRX WHERE trx_state LOCK WAIT; SELECT * FROM sys.innodb_lock_waits;sys库的innodb_lock_waits会把阻塞方和被阻塞方的线程ID、事务ID、锁模式、等待时间全部关联起来比去information_schema手动关联多张表方便太多了。6.3 高并发场景下典型的死锁案例最常见的死锁案例之一是两个事务以不同的顺序更新两张表事务A先UPDATE订单表再UPDATE库存表。事务B先UPDATE库存表再UPDATE订单表。当A、B交叉执行时A持有订单表行锁等待库存表B持有库存表行锁等待订单表死锁立刻发生。解法所有事务都按同一个顺序访问资源比如约定始终先处理库存表再处理订单表。这算是“约定式”解法靠代码规范来规避。另一个常见死锁发生在批量操作同一张表但范围交叉。比如-- 事务A UPDATE inventory SET quantity quantity - 1 WHERE id IN (1, 3, 5); -- 事务B UPDATE inventory SET quantity quantity - 1 WHERE id IN (5, 7, 1);两个事务都需要锁id1和id5但加锁顺序不同。MySQL是按索引扫描顺序加锁的如果执行计划某个范围先锁了1再锁5另一个先锁了5再锁1就会形成循环等待。对这种场景我的建议是大批量操作时先对主键排序再逐一处理或者直接把SQL改写为同一个固定顺序。和“资源访问顺序一致”是同一个原则。6.4 从单库锁到分布式锁跨系统后你的思维要变单体MySQL时代锁是数据库内部机制DBA和开发者只需要关注SQL怎么写。但当系统拆分成了订单服务、库存服务、支付服务每个服务都有独立的库数据库行锁就管不到跨库的一致性了。这时候就需要引入分布式锁。合法的分布式锁实现不外乎几种基于Redis的SETNXLua脚本、基于ZooKeeper的临时顺序节点、基于数据库本身的唯一约束或SELECT FOR UPDATE。选型时重点考虑四点是否需要可重入锁的自动过期时间设多长持有锁的业务异常宕机后能否被正确释放锁服务自身的高可用等级。另外和MySQL事务锁一样分布式锁同样有“粒度”问题。锁的粒度越细并发能力越强但实现复杂度也越高。比如库存扣减可以锁SKU维度也可以锁仓库SKU组合维度。我见过有些系统因为锁粒度太粗把一个仓库下的所有SKU都锁住了结果不同商品之间互相影响并发能力下降了一个数量级。所以我一直强调无论是数据库锁还是分布式锁设计之前先想清楚“并发冲突的边界在哪里”锁的对象越小系统能撑住的流量越大。这是一个架构层面比技术选型更重要的问题。在实际运营系统时我个人的体感是事务、锁、MVCC这套东西不是你读过一遍就永远会用而是在真正遇到线上事故、每次排查告警时逐渐内化的。今天分享的这些案例和排查链路基本都是那些让我“睡不着觉”的故障换来的经验。如果你正在构建高并发数据系统我的建议很朴素先把你线上每条重要SQL的EXPLAIN跑一遍确认索引命中再把所有事务的大小和锁持有时间列一张清单最后建立一套死锁告警和现场快照抓取的机制。这三件事做完你的系统就已经比大多数同行稳健了。 
长河君 · 2026/10/1 3:58:40 · 阅读 1.2k 深入MySQL事务与锁机制：从超卖事故到高并发系统实战
作为一个在后端和数据架构领域摸爬滚打多年的从业者我越来越深刻地感受到一件事高并发系统里那些看似诡异的数据错乱、库存超卖、重复下单事故到最后排查原因往往都能归结到对事务隔离级别、锁机制和MVCC底层逻辑的理解不到位。很多人把“事务四大特性”“锁的粒度”背得滚瓜烂熟但真到了线上出问题——比如订单表明明有索引却还是锁住了全表、两个接口偶发性死锁、主从延迟后读到旧数据——就开始抓瞎。这篇文章不打算从《数据库原理》教材第一章讲起而是直接从实际发生过的故障和性能瓶颈切入把MySQL事务与锁在构建高并发数据系统时真正需要吃透的关键点掰开揉碎了讲清楚。适合正在做电商、支付、IM、库存系统这类强一致性业务的开发同学也适合刚入门但不想背死知识、想真正理解数据库底层行为的工程师。1. 从一次线上扣库存事故说起事务与锁到底在解决什么1.1 一次真实的超卖事故有次接手一个生鲜电商系统的优化工作线上反馈说“限时抢购时库存会变成负数”。代码逻辑看起来天衣无缝Transactional public boolean deductStock(Long skuId, Integer count) { // 1. 查询当前库存 Stock stock stockMapper.selectBySkuId(skuId); // 2. 校验库存是否充足 if (stock.getAvailable() count) { return false; } // 3. 扣减库存 stock.setAvailable(stock.getAvailable() - count); stockMapper.updateById(stock); return true; }这个代码在低并发下跑得飞快但一旦瞬间涌入大量请求问题就暴露了两个事务同时读到available10同时判断“105”成立然后都往库里面写最终结果变成了5而不是期望的0。这就是典型的并发事务相互干扰问题。事务A读到的数据、事务B读到的数据在各自事务提交之前都可能是不完整、不稳定的中间状态。所谓ACID其实核心就是在回答一个问题当大量事务同时操作同一批数据时系统凭什么保证最终结果是正确的1.2 事务的隔离性并不是“玄学”很多同学对ACID的A原子性、C一致性、I隔离性、D持久性都能说上一两句但落地到真实系统里最容易被忽视也最致命的是隔离性。隔离性并不是说“多个事务之间完全看不见对方”而是通过一套复杂的并发控制机制在“性能”和“正确性”之间做权衡。MySQL InnoDB引擎用一套组合拳来解决并发问题锁Locking通过独占资源来阻止并发操作同一行数据。MVCC多版本并发控制通过保存数据的多个版本来让读操作不阻塞写操作。事务日志Undo Log / Redo Log保证原子性和持久性同时为MVCC提供底层支持。这三者不是独立存在的而是协同工作的。理解它们之间的配合比单独背诵任何一个概念都有用得多。接下来我先从隔离级别入手因为这是事务机制的“总开关”。2. 隔离级别的取舍为什么MySQL默认用可重复读2.1 四种隔离级别与三个“读异常”SQL标准定义了四种隔离级别分别对应解决不同程度的数据一致性问题。我习惯用一个表格把它们的关系先列出来隔离级别脏读不可重复读幻读Read Uncommitted读未提交可能可能可能Read Committed读已提交不会可能可能Repeatable Read可重复读不会不会可能InnoDB已解决Serializable串行化不会不会不会脏读事务A修改了一条数据但还没提交事务B就读到了修改后的值。如果事务A回滚事务B读到的就是一个“根本不存在过”的数据。不可重复读事务A第一次读某行数据是10事务B把这行改成20并提交事务A第二次读就变成了20。同一事务内两次读同一行数据结果不一致。幻读事务A按某个条件查询第一次查到5条记录事务B插入了一条新纪录并提交事务A再次查询变成了6条。重点是新增了一条之前不存在的记录而不是某一行的值变了。读未提交和串行化基本属于两个极端前者太不安全后者性能太差。实际生产环境常见的只有两个选择Read Committed 和 Repeatable Read。2.2 MySQL为什么把默认值设为Repeatable ReadOracle、PostgreSQL这些数据库默认隔离级别是Read Committed但MySQL InnoDB的默认是Repeatable Read。这里有个关键点容易被误解MySQL的Repeatable Read通过间隙锁Gap Lock机制已经解决了幻读问题所以在这个级别下它实际上接近了SQL标准中Serializable的正确性但仍然保留了较高的并发性能。我自己的理解是MySQL当年选择RR作为默认既有历史兼容性的考虑MySQL 5.0之前的主从复制中binlog格式和隔离级别有绑定关系也有实际业务场景的考量——很多金融、订单类业务天然需要在一个事务里重复读取同一批数据并保证结果一致。2.3 实际项目中如何选择隔离级别实践里我的建议比较直接默认使用RRMySQL默认但必须理解其底层原理不要盲目修改。如果业务对“深度一致性”要求不高、且主要做读多写少的报表分析类系统可以考虑改成Read Committed来减少间隙锁带来的锁竞争。我经历过的几个高并发订单系统最终都保留RR但把很多业务逻辑拆成了“先快照读再当前读”的模式。原因是RR下的快照读天然具备一致性非锁定读的特性对报表、统计类查询非常友好。一个非常反直觉的坑是RR级别下如果先做了一次快照读普通SELECT后来在同一事务里做当前读SELECT FOR UPDATE或者UPDATEMySQL会使用当前读的版本这可能导致数据显示“异常前后不一致”很多初学者在这里栽过跟头。3. 锁的分类与兼容性全局锁、表锁、行锁与意向锁3.1 锁粒度决定并发上限InnoDB支持三种粒度的锁全局锁锁整个实例通常用于全库备份。FLUSH TABLES WITH READ LOCK 会阻塞所有写操作。除非做物理备份否则线上环境基本不建议用。表锁锁定整个表InnoDB在DDL操作或者某些特殊场景下会使用但也提供了LOCK TABLES命令手动加锁。行锁InnoDB真正强大的地方锁定的粒度是索引记录。只有通过索引条件检索数据时InnoDB才会使用行锁否则会升级为表锁这是一个经典的坑后面重点说。从并发性能来说行锁 表锁 全局锁。锁粒度越细并发度越高但锁管理的代价也越大。InnoDB的行锁是通过给索引项加锁实现的所以行锁必须有索引作为前提且索引要能让执行计划精准定位到记录。3.2 意向锁与锁兼容矩阵有一类锁容易被人忽略意向锁Intention Lock。它其实是个“标记”性质的锁核心目的是让表锁和行锁之间快速判断是否有冲突避免每次要加表锁时扫描全表的行锁。这玩意儿有点像你进会议室之前在门口白板上写字“里面有人”后来的人不用推门看看白板就知道这间会议室现在能不能进。意向锁分两种意向共享锁IS锁事务打算给某些行加共享锁。意向排他锁IX锁事务打算给某些行加排他锁。InnoDB的锁兼容矩阵如下锁类型共享锁S排他锁X意向共享锁IS意向排他锁IX共享锁S兼容冲突兼容冲突排他锁X冲突冲突冲突冲突意向共享锁IS兼容冲突兼容兼容意向排他锁IX冲突冲突兼容兼容记这个表不用死背只需要掌握一条底层逻辑任何锁之间只有“读读”是兼容的“读写”和“写写”都必须互斥。意向锁本身没有改变行锁之间的兼容关系它的存在只是为了快速判断表级锁是否与已有行锁冲突。3.3 悲观锁与乐观锁两种截然不同的并发控制思路切入到业务代码层面锁还可以分为悲观锁和乐观锁这个也是BAT面试的高频考点。悲观锁的逻辑是“我悲观地认为并发冲突一定会发生”所以先拿锁再干活。最典型的实现就是SELECT ... FOR UPDATE。这种做法的优点是绝对安全缺点是锁等待会拖垮吞吐量。-- 事务A BEGIN; SELECT * FROM stock WHERE sku_id 1001 FOR UPDATE; -- 假设查询到库存为10 UPDATE stock SET available available - 5 WHERE sku_id 1001; COMMIT;在上面的SQL中事务A执行的第一条SELECT FOR UPDATE会把sku_id1001这行锁住事务B如果也执行同样的语句会一直阻塞直到A提交。在没有索引的情况下这句会在全表加锁切记。乐观锁的逻辑是“我乐观地认为并发冲突不常见”所以不先拿锁而是在更新时检查版本号或状态是否发生了变化。典型实现UPDATE stock SET available available - 5, version version 1 WHERE sku_id 1001 AND version 10; -- 如果影响行数为0说明版本已变化需要重试这里最核心的技术点是UPDATE语句本身在InnoDB中就是一个排他锁操作即使你不用SELECT FOR UPDATE引擎也会对命中行加X锁。乐观锁的关键在于通过WHERE条件让冲突的更新“自动失效”更准确的说法是它在应用层做并发控制数据库层只是正常执行单行更新。我的经验是秒杀、抢购这类“写入并发极高”的场景乐观锁重试机制往往好用而账务操作、库存预占这类“冲突概率高且不容失败”的场景悲观锁反而更可控因为重试的代价可能比等待锁更昂贵。4. MVCC的底层逻辑快照读与当前读4.1 一条记录的版本链是怎么生成的很多人以为MVCC就是简单的“读写分离”其实底层靠的是Undo Log版本链和Read View机制。每次对记录进行修改InnoDB不会直接覆盖旧数据而是将旧数据放入Undo Log中新数据生成一个新的版本号事务ID版本之间通过指针串成一条链。所有版本构成一个链表最新版本在链表的头部。举个例子-- 初始版本基于事务T1插入值为100 INSERT INTO account(id, balance) VALUES(1, 100); -- 事务T2修改余额变为200 UPDATE account SET balance 200 WHERE id 1;此时这条记录上有两个版本V1(balance100, 事务T1创建)V2(balance200, 事务T2创建)V2的roll_pointer指向V1。如果事务T3又改了余额变成300就会生成V3并指向V2。4.2 Read View的可见性判断规则当事务执行快照读时InnoDB会生成一个Read View里面记录了几个关键信息m_ids生成Read View时当前活跃未提交事务的ID列表。min_trx_idm_ids中最小的活跃事务ID。max_trx_id生成Read View时InnoDB分配的下一个事务ID也就是当前系统之内未来可能产生的事务ID的上限。creator_trx_id生成Read View的事务自己的ID。判断一条记录的某个版本是否可见规则是这样的如果被访问版本的trx_id creator_trx_id自己改的当然能看见。如果被访问版本的trx_id min_trx_id说明该版本在Read View生成前就已经提交可见。如果被访问版本的trx_id max_trx_id说明该版本是由未来事务生成的不可见。如果min_trx_id trx_id max_trx_id需要判断trx_id是否在m_ids中如果在说明还活跃未提交不可见如果不在已经提交可见。这个判断逻辑每访问一条记录的每个版本都要执行一遍如果版本链很长性能损耗很明显。这也是为什么我一直劝别人别在大表上频繁做长事务——版本链太长会导致快照读变慢。4.3 快照读与当前读的本质差异快照读Snapshot Read普通的SELECT语句。读取的是记录在某个时间点的快照版本不需要加锁所以不会阻塞其他事务的写操作。这就是“读不阻塞写”的底层原因。当前读Current ReadSELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE这些操作读到的是记录的最新版本并且必须加锁。这就是“写阻塞写”的原因。为什么UPDATE不能走快照读因为如果更新基于旧版本会导致覆盖更新。永远记住这个公式当前读 最新版本 锁保护。在RR隔离级别下同一个事务里多次快照读会复用同一个Read View这就是可重复读的实现。在Read Committed级别下每次快照读都会生成新的Read View所以会出现不可重复读的问题。5. 高并发系统的性能杀手大事务、长持有锁与索引失效5.1 大事务引发的Undo Log膨胀与主从延迟事务的大小直接影响MySQL的整体性能。一个事务操作了10万行回滚段里的Undo Log就会非常庞大占用的磁盘和内存资源随之暴涨。更麻烦的是事务提交后Undo Log还不能立即清理因为可能有其他事务的Read View还在引用这些旧版本。如果一直有长查询存活Undo Log就会被长期保留这就是很多人线上“磁盘空间莫名其妙暴涨”的幕后推手之一。我处理过一个典型案例某财务系统每天凌晨批量跑对账事务单条事务最多处理超过50万条记录运行期间主库磁盘使用率飙升到90%以上从库延迟从秒级变成小时级最后整个报表链路全部阻塞。那种感觉就像一个人一次性吃了一周的饭消化系统直接瘫了。解决办法把大事务拆成小事务。最简单有效的方式是分批提交比如每500条或每1000条一个事务。虽然事务数量变多了但每个事务的持有锁时间极短Undo Log也小整体系统反而更稳。5.2 “行锁变表锁”的经典陷阱与排查方法InnoDB的行锁依赖于索引。如果条件列没有索引数据库就只能全表扫描然后把所有扫描到的记录都锁住——这在效果上等于表锁。有个血的教训一张订单明细表原来在order_id上有索引后面为了某个查询需求新加了一个字段但没建索引。某次运营活动按新字段做批量更新一条UPDATE语句直接把整张表锁住十几个小时所有订单操作全部阻塞线上报警电话被打爆。检查是否有索引其实非常快SHOW INDEX FROM order_detail; EXPLAIN SELECT * FROM order_detail WHERE user_phone 13800138000;EXPLAIN里看到typeALL或者rows预估很高就要警惕了。经验法则UPDATE和DELETE的WHERE条件必须命中索引哪怕是一个选择性不高的索引也好过全表扫描加锁。5.3 锁等待超时与参数调优高并发下最头疼的问题之一就是锁等待。MySQL默认的锁等待时间是50秒SHOW VARIABLES LIKE innodb_lock_wait_timeout;设成50秒的本意是给大事务留足时间但实际在高并发场景下50秒的锁等待会让所有线程都堆死在那里连接池被打满整个服务雪崩。我的做法是根据业务接口的RT要求调整这个值。比如订单扣库存的接口要求200ms内返回那锁等待就配成3秒左右超过时间直接报错让上层走重试或降级。与其傻等不如快速失败把错误暴露出来让链路快速切换。SET GLOBAL innodb_lock_wait_timeout 3; SET SESSION innodb_lock_wait_timeout 3;注意这两条命令的作用范围不一样全局设置不会影响已经存在的连接需要新连接才会生效。还有一个关键参数是innodb_lock_wait_timeout和死锁检测的配合。如果开了死锁检测默认开启事务发生死锁时MySQL会主动回滚一个事务表面上表现为报错“Deadlock found when trying to get lock”实际的处理逻辑是快速牺牲一个事务来换取系统继续运行。6. 死锁排查链路从告警到最终修复的实操记录6.1 死锁的必要条件与InnoDB的处理策略死锁说白了就是两个或多个事务各自持有一把锁同时等待对方释放自己需要的锁。理论上死锁需要四个条件互斥、持有并等待、不可剥夺、循环等待。InnoDB处理死锁的策略很简单牺牲一个事务回滚它释放它持有的所有锁让其他事务继续执行。被牺牲的事务会收到一条错误提示通常是ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction这意味着应用层必须有重试机制。没有重试机制的死锁处理等于没处理。6.2 定位死锁的完整排查SQL每次遇到死锁告警我先做的不是猜而是把现场情况捞出来。最重要的命令SHOW ENGINE INNODB STATUS;这个命令会输出LATEST DETECTED DEADLOCK一栏里面详细记录了死锁发生时的两条事务各自执行到了哪条SQL、持有什么锁、等待什么锁。再看TRANSACTIONS一节找到当前所有活跃事务的等待状态。为了让排查更精准我通常还会查询SELECT * FROM information_schema.INNODB_TRX WHERE trx_state LOCK WAIT; SELECT * FROM sys.innodb_lock_waits;sys库的innodb_lock_waits会把阻塞方和被阻塞方的线程ID、事务ID、锁模式、等待时间全部关联起来比去information_schema手动关联多张表方便太多了。6.3 高并发场景下典型的死锁案例最常见的死锁案例之一是两个事务以不同的顺序更新两张表事务A先UPDATE订单表再UPDATE库存表。事务B先UPDATE库存表再UPDATE订单表。当A、B交叉执行时A持有订单表行锁等待库存表B持有库存表行锁等待订单表死锁立刻发生。解法所有事务都按同一个顺序访问资源比如约定始终先处理库存表再处理订单表。这算是“约定式”解法靠代码规范来规避。另一个常见死锁发生在批量操作同一张表但范围交叉。比如-- 事务A UPDATE inventory SET quantity quantity - 1 WHERE id IN (1, 3, 5); -- 事务B UPDATE inventory SET quantity quantity - 1 WHERE id IN (5, 7, 1);两个事务都需要锁id1和id5但加锁顺序不同。MySQL是按索引扫描顺序加锁的如果执行计划某个范围先锁了1再锁5另一个先锁了5再锁1就会形成循环等待。对这种场景我的建议是大批量操作时先对主键排序再逐一处理或者直接把SQL改写为同一个固定顺序。和“资源访问顺序一致”是同一个原则。6.4 从单库锁到分布式锁跨系统后你的思维要变单体MySQL时代锁是数据库内部机制DBA和开发者只需要关注SQL怎么写。但当系统拆分成了订单服务、库存服务、支付服务每个服务都有独立的库数据库行锁就管不到跨库的一致性了。这时候就需要引入分布式锁。合法的分布式锁实现不外乎几种基于Redis的SETNXLua脚本、基于ZooKeeper的临时顺序节点、基于数据库本身的唯一约束或SELECT FOR UPDATE。选型时重点考虑四点是否需要可重入锁的自动过期时间设多长持有锁的业务异常宕机后能否被正确释放锁服务自身的高可用等级。另外和MySQL事务锁一样分布式锁同样有“粒度”问题。锁的粒度越细并发能力越强但实现复杂度也越高。比如库存扣减可以锁SKU维度也可以锁仓库SKU组合维度。我见过有些系统因为锁粒度太粗把一个仓库下的所有SKU都锁住了结果不同商品之间互相影响并发能力下降了一个数量级。所以我一直强调无论是数据库锁还是分布式锁设计之前先想清楚“并发冲突的边界在哪里”锁的对象越小系统能撑住的流量越大。这是一个架构层面比技术选型更重要的问题。在实际运营系统时我个人的体感是事务、锁、MVCC这套东西不是你读过一遍就永远会用而是在真正遇到线上事故、每次排查告警时逐渐内化的。今天分享的这些案例和排查链路基本都是那些让我“睡不着觉”的故障换来的经验。如果你正在构建高并发数据系统我的建议很朴素先把你线上每条重要SQL的EXPLAIN跑一遍确认索引命中再把所有事务的大小和锁持有时间列一张清单最后建立一套死锁告警和现场快照抓取的机制。这三件事做完你的系统就已经比大多数同行稳健了。