核心内容摘要
AI Coding——Trae
在MySQL数据库的高并发场景中锁机制是保障数据一致性、解决并发冲突的核心基石而InnoDB存储引擎的锁设计更是其能支撑高并发业务的关键所在。
从最基础的S锁共享锁、X锁排他锁到行级锁细分的记录锁、间隙锁再到解决幻读的终极方案Next-Key LockMySQL的锁机制形成了一套从粗粒度到细粒度、从基础控制到精准防护的完整体系。
很多开发者在实际开发中常会遇到死锁、锁等待、幻读等问题本质上是对锁机制的底层实现、生效规则及适用场景理解不透彻。
本文将从底层原理出发专业、全面地拆解MySQL锁机制的完整逻辑结合实战场景分析各类锁的使用特点与触发条件同时结合高并发业务趋势给出锁机制的优化思路与前瞻性建议帮助开发者真正吃透锁机制从根源上解决并发问题。
锁机制的核心前提存储引擎与隔离级别的双重约束MySQL的锁机制并非统一实现其表现形式、粒度与能力高度依赖存储引擎同时受事务隔离级别直接影响这是理解所有锁类型的基础前提也是开发者最易忽略的核心要点。
存储引擎的锁能力差异MySQL中主流的存储引擎为MyISAM和InnoDB二者的锁设计存在本质区别MyISAM仅支持表级锁实现简单但粒度粗在写操作时会锁定整个表导致读写互斥无法支撑高并发写业务目前仅适用于纯读或读多写极少的场景InnoDB作为MySQL默认的存储引擎是为高并发设计的支持表级锁、行级锁同时引入意向锁做协调行级锁是其核心优势能实现精准的行级资源控制大幅提升并发处理能力。
此外InnoDB的锁机制与事务紧密结合依托MVCC多版本并发控制实现“无锁读”让读操作尽可能不阻塞写操作进一步提升并发效率。
事务隔离级别的锁影响MySQL定义了四种事务隔离级别读未提交READ UNCOMMITTED、读已提交READ COMMITTEDRC、可重复读REPEATABLE READRR、串行化SERIALIZABLE其中InnoDB默认采用可重复读RR这也是Next-Key Lock等核心锁类型的生效基础。
不同隔离级别下InnoDB的锁策略、幻读/不可重复读的解决能力截然不同读已提交RC仅支持记录锁无间隙锁和Next-Key Lock无法彻底解决幻读可重复读RR通过Next-Key Lock实现了幻读的彻底解决是平衡并发性能与数据一致性的最优选择串行化则直接将所有事务按顺序执行完全避免并发冲突但牺牲了并发能力几乎不用于生产高并发场景。
简言之InnoDB的锁机制是**“存储引擎为体隔离级别为用”**后续所有锁类型的分析均基于InnoDB存储引擎且重点围绕RC和RR两大核心隔离级别展开。
基础基石S锁共享锁与X锁——锁机制的核心二元逻辑S锁Shared Lock共享锁和X锁Exclusive Lock排他锁是InnoDB最基础、最核心的锁类型构成了锁机制的二元逻辑所有复杂的锁类型均基于此延伸而来。
二者遵循**“共享兼容、排他互斥”**的核心原则且均支持表级和行级两个维度不同维度的锁在粒度、适用场景、性能影响上差异显著。
1 核心定义与原生特性S锁共享锁又称“读锁”专为只读操作设计加锁后不会修改数据核心特性是多事务兼容——多个事务可同时对同一资源加S锁实现并发读这是保障读操作高性能的关键。
显式加锁方式SELECT ... LOCK IN SHARE MODE;而InnoDB中普通的SELECT操作默认不加锁依托MVCC实现“快照读”属于无锁读避免了读操作阻塞写操作这是InnoDB高并发的重要设计X锁排他锁又称“写锁”专为数据修改操作增、删、改设计核心特性是完全互斥——同一资源只能被一个事务加X锁且与任何锁S锁、X锁均互斥从根本上杜绝了多事务同时修改同一资源的并发冲突保障数据修改的原子性。
显式加锁方式SELECT ... FOR UPDATE;而InnoDB中INSERT、UPDATE、DELETE操作会自动为目标资源加行级X锁无需手动干预这是默认的写操作防护策略。
2 表级S/X锁 vs 行级S/X锁粒度决定性能表级S/X锁和行级S/X锁的核心差异在于锁粒度而粒度直接决定了并发性能和阻塞范围InnoDB的核心设计思路是**“优先使用行级锁按需升级为表级锁”**以此平衡并发性能和锁管理成本。
锁维度核心特性加锁触发场景性能影响适用场景表级S锁多事务可同时加锁与表级X锁互斥显式执行LOCK TABLES 表名 READ;或无索引时的批量读操作阻塞所有对该表的X锁操作增、删、改读操作可并发纯读场景的全表查询、无索引的批量读表级X锁单事务独占与所有表级锁互斥显式执行LOCK TABLES 表名 WRITE;或无索引时的任意写操作阻塞该表的所有读写操作并发性能极差极少使用仅适用于全表批量更新的特殊场景行级S锁不同行可并发加锁同一行多事务可加S锁与同一行X锁互斥显式执行SELECT ... LOCK IN SHARE MODE;且有索引精准匹配仅阻塞目标行的X锁操作其他行读写不受影响需保证读操作一致性的精准查询如多事务协同读某条核心数据行级X锁同一行单事务独占与所有行级锁互斥INSERT/UPDATE/DELETE有索引精准匹配或显式SELECT ... FOR UPDATE;有索引仅阻塞目标行的所有读写操作并发性能最优绝大多数高并发场景的单条/批量精准数据修改
3 行级锁的关键前提依赖索引实现这里有一个开发者极易踩坑的点InnoDB的行级锁是基于索引实现的而非基于物理行。
InnoDB是索引组织表所有数据均存储在聚簇索引主键索引中二级索引最终也会指向聚簇索引因此行级锁本质上是锁定索引记录而非直接锁定物理数据行。
如果执行加锁操作时查询条件没有使用索引包括主键索引、二级索引InnoDB无法精准定位到具体的行此时会将行级锁升级为表级X锁导致整个表被锁定引发严重的锁阻塞。
例如表user有主键id无索引name执行UPDATE user SET age20 WHERE namezhangsan;时InnoDB会全表扫描最终加表级X锁这是高并发场景中锁等待的常见原因。
此外若使用二级索引加锁InnoDB会先锁定二级索引的记录再通过二级索引指向的主键锁定聚簇索引的对应记录即**“二级索引加锁聚簇索引必加锁”**这也是死锁的常见触发点之一。
4 核心规则必记的S/X锁互斥兼容原则同一资源的锁互斥/兼容S-S兼容、S-X互斥、X-X互斥这是所有锁冲突的底层逻辑锁粒度的优先级表级锁 行级锁表级锁会阻塞该表所有行的操作行级锁仅阻塞目标索引记录对应的行加锁的自动策略InnoDB默认优先行级锁无索引时自动升级为表级锁无需手动干预写操作的默认加锁所有数据修改操作增、删、改只要有索引均自动加行级X锁这是保障写操作原子性的基础。
行级锁的细分记录锁Record Lock与间隙锁Gap Lock——从“锁定已有”到“防护空白”在RR和RC隔离级别下InnoDB的行级锁会细分为记录锁Record Lock和间隙锁Gap Lock二者是构成Next-Key Lock的基础也是解决“不可重复读”和“幻读”的关键。
其中记录锁是基础的行级锁而间隙锁是InnoDB为解决RR隔离级别下的幻读问题专门设计的仅在RR隔离级别生效RC隔离级别无间隙锁这是两大隔离级别锁策略的核心差异。
1 记录锁Record Lock锁定已有索引记录的“基础行锁”核心定义记录锁是锁定具体的某一条已存在的索引记录的行级锁仅锁定记录本身不锁定记录之间的间隙是InnoDB最基础的行级锁。
核心特性只对已存在的索引记录生效不阻止其他事务向记录之间的间隙插入新数据因此单独的记录锁无法解决幻读问题。
生效场景读已提交RC隔离级别下的所有行级加锁操作RC仅支持记录锁可重复读RR隔离级别下唯一索引的精准等值查询如主键等值匹配、唯一二级索引等值匹配实战示例假设表user有主键id1,3,5RR隔离级别下事务A执行UPDATE user SET nametest WHERE id3;因主键是唯一索引且精准匹配InnoDB会对id3的聚簇索引记录加行级X锁Record Lock仅锁定id3这一行其他事务可正常向(1,
、(3,
的间隙插入id
id4的数据也可正常修改id
id5的记录。
2 间隙锁Gap Lock锁定索引间隙的“幻读防护锁”核心定义间隙锁是锁定两个相邻索引记录之间的间隙的锁同时也包括“第一条索引记录之前的间隙”和“最后一条索引记录之后的间隙”即**“开区间”锁**仅锁定间隙不锁定具体的索引记录本身。
核心特性只阻止插入操作不阻止修改和查询——间隙锁的唯一作用是防止其他事务向锁定的间隙中插入新的索引记录从根源上避免新数据的产生这是解决幻读问题的关键对已有记录的修改、查询操作间隙锁不做任何阻塞。
生效场景仅在可重复读RR隔离级别下生效且满足以下条件之一非唯一索引的任意查询/修改加锁操作等值、范围唯一索引的范围查询加锁操作非精准等值无索引的加锁操作已升级为表级锁本质是锁定整个表的所有间隙实战示例同上述表user主键id1,3,5RR隔离级别下事务A执行UPDATE user SET nametest WHERE id 1 AND id 5;这是主键的范围查询InnoDB会对id3加Record Lock同时对两个间隙加Gap Lock(1,
和(3,
。
此时其他事务无法向这两个间隙插入id
id4的数据但可正常修改id
id
id5的已有记录也可向(5, ∞)的间隙插入id6的数据。
关键补充间隙锁的锁定范围基于索引的有序性而非物理行的顺序即使某条索引记录被删除其对应的间隙仍会被锁定直到事务提交。
例如若删除id3再执行id1 AND id5的范围查询(1,
的间隙仍会被锁定防止插入新数据。
3 记录锁与间隙锁的协同解决不同的并发问题记录锁和间隙锁的设计各有侧重二者协同构成了RR隔离级别下锁机制的基础记录锁解决不可重复读问题——锁定已有记录防止其他事务修改保证同一事务内多次读取同一记录的结果一致间隙锁解决幻读的核心环节——锁定间隙防止其他事务插入新数据避免同一事务内多次范围查询的结果集出现新增数据而RC隔离级别因无间隙锁仅靠记录锁无法阻止插入因此只能解决不可重复读无法彻底解决幻读这也是InnoDB将RR设为默认隔离级别的重要原因。
终极方案Next-Key Lock临键锁——RR隔离级别下的默认锁策略彻底解决幻读Next-Key Lock是InnoDB在可重复读RR隔离级别下为行级锁设计的默认实现方式是Record Lock和Gap Lock的组合体也是InnoDB彻底解决幻读问题的终极方案。
其设计思路是**“既锁定已有记录又锁定记录周围的间隙”**形成一个连续的锁区间让范围查询的加锁操作实现“全范围防护”。
1 核心定义与区间规则核心定义Next-Key Lock Record Lock锁定当前索引记录 Gap Lock锁定当前记录的前驱间隙即锁定一个左开右闭的索引区间(prev_record, current_record]。
区间规则InnoDB的索引是有序的升序Next-Key Lock会以查询条件匹配到的索引记录为基准向左锁定到上一条相邻的索引记录形成前驱间隙向右锁定到当前索引记录本身构成左开右闭的区间若查询条件匹配到多条索引记录则会为每条记录生成对应的Next-Key Lock最终形成连续的锁区间。
核心目的彻底解决幻读问题——通过“记录锁间隙锁”的组合既锁定已有记录防止修改又锁定间隙防止插入保证同一事务内多次范围查询的结果集完全一致实现RR隔离级别的核心承诺。
2 核心生效规则按需退化兼顾性能与防护Next-Key Lock虽是RR隔离级别下的默认锁策略但并非所有场景都会保持完整的组合形态InnoDB会根据索引类型和查询方式自动退化为Record Lock或Gap Lock以此兼顾锁的防护能力和并发性能——这是InnoDB锁机制的精妙设计也是开发者需要重点掌握的要点。
规则1唯一索引的精准等值查询且记录存在 → 退化为Record Lock唯一索引主键、唯一二级索引的精准等值查询能精准定位到唯一的一条索引记录且记录存在时无需锁定间隙唯一索引保证不会插入重复的记录无幻读风险因此Next-Key Lock会自动退化为Record Lock仅锁定该条记录提升并发性能。
示例主键id3精准查询记录存在退化为Record Lock仅锁定id3。
规则2唯一索引的精准等值查询且记录不存在 → 退化为Gap Lock唯一索引的精准等值查询若记录不存在无索引记录可加Record Lock此时Next-Key Lock会退化为Gap Lock仅锁定查询条件对应的间隙防止其他事务插入该记录避免后续同一事务查询出现“幻读”。
示例主键id2精准查询记录不存在退化为Gap Lock仅锁定(1,
的间隙防止插入id2。
规则3非唯一索引的任意查询等值/范围 → 保持完整的Next-Key Lock非唯一索引的查询即使是等值查询也可能匹配到多条记录索引值重复且无法保证后续不会插入相同索引值的记录因此会保持完整的Next-Key Lock为每条匹配的记录生成(prev_record, current_record]的区间锁同时锁定所有相关间隙。
实战示例表user有非唯一索引age20,25,25,30RR隔离级别下执行UPDATE user SET nametest WHERE age25;因age是非唯一索引等值查询匹配到两条记录会生成两个连续的Next-Key Lock区间(20,25]和(25,30]最终合并为(20,30]的连续区间既锁定age25的两条记录Record Lock又锁定(20,
、(25,
的间隙Gap Lock防止插入age
age26等数据。
规则4唯一索引的范围查询 → 保持完整的Next-Key Lock唯一索引的范围查询无法精准定位到单条记录可能匹配到多条记录且后续可能插入新的记录到范围区间内因此会保持完整的Next-Key Lock为每条匹配的记录生成对应的区间锁。
示例主键id1 AND id5的范围查询生成(1,3]和(3,5]两个Next-Key Lock区间合并为(1,5]既锁定id3的记录又锁定(1,
、(3,
的间隙。
3 Next-Key Lock的实战价值平衡一致性与并发性能Next-Key Lock的设计体现了InnoDB“精准防护按需退化”的核心思想对需要全范围防护的场景非唯一索引、范围查询保持完整的Next-Key Lock彻底解决幻读保障数据一致性对无需防护间隙的场景唯一索引精准查询自动退化为Record Lock减少锁的粒度提升并发性能这种设计让RR隔离级别既实现了比RC更高的数据一致性彻底解决幻读又不会过度牺牲并发性能成为高并发场景的最优选择。
辅助协调意向锁Intention Lock——表级锁与行级锁的“沟通桥梁”在理解了行级锁的核心类型后我们需要引入意向锁Intention Lock——一种InnoDB自动添加和释放的表级锁其设计目的是解决表级锁与行级锁之间的冲突检测效率低下问题是锁机制中不可或缺的辅助协调层开发者无需手动操作但需理解其底层逻辑否则易误解锁冲突的原因。
1 核心定义与分类意向锁是事务在对某一行加行级锁之前先对整个表加的一种“意向声明”锁告诉数据库“本事务即将对该表的某一行加行级锁请表级锁操作提前做出判断”。
意向锁分为两类与S锁、X锁一一对应意向共享锁IS Lock事务想要对某一行加S锁之前先对该表加IS锁意向排他锁IX Lock事务想要对某一行加X锁之前先对该表加IX锁。
2 核心特性与互斥规则意向锁是表级锁但与普通的表级S/X锁不同其核心特性是“声明意向不阻塞行操作”互斥规则也有明确的限定核心规则可
总结为3点意向锁之间互相兼容IS-IS、IS-IX、IX-IX之间均兼容因为意向锁只是“声明即将加行级锁”不同事务的行级锁可能锁定不同的行无需互相阻塞意向锁与表级S/X锁互斥表级锁是粗粒度锁会锁定整个表因此与意向锁存在严格的互斥关系表级S锁 ↔ 表级IX锁互斥表级S锁允许其他事务加表级S锁但不允许加行级X锁而IX锁声明即将加行级X锁表级X锁 ↔ 表级IS/IX锁均互斥表级X锁独占整个表不允许任何其他锁操作意向锁与行级锁不互斥行级锁是细粒度锁锁定具体的行意向锁仅做表级的意向声明二者无直接冲突行级锁的互斥规则仍遵循S/X锁的核心原则。
3
核心价值提升锁冲突的检测效率在没有意向锁的情况下若一个事务想要加表级X锁数据库需要遍历整个表的所有行检查是否有其他事务加了行级锁若表的数据量极大这个过程会消耗大量的系统资源检测效率极低。
而意向锁的引入让数据库只需检测表级的意向锁即可判断是否能加表级锁若表上有IX锁说明已有事务即将加行级X锁此时无法加表级S锁若表上有IS/IX锁说明已有事务即将加行级锁此时无法加表级X锁无需遍历所有行大幅提升了锁冲突的检测效率减少了系统开销这是InnoDB能高效支撑高并发的重要细节设计。
MySQL锁机制的实战问题与解决方案死锁、锁等待理解了锁机制的底层逻辑后我们需要结合生产场景分析两个最常见的锁问题死锁和锁等待并从锁机制的角度给出解决方案这是将理论落地的核心环节。
1 死锁多事务互相持有对方需要的锁形成循环等待死锁是指两个或多个事务在执行过程中互相持有对方需要的锁且均不释放自己持有的锁形成循环等待最终导致所有事务无法继续执行。
InnoDB的行级锁是死锁的主要触发场景因为表级锁只会导致锁等待不会形成循环。
死锁的常见触发原因多事务加锁的顺序不一致这是最常见的原因例如事务A先加id1的X锁再尝试加id2的X锁事务B先加id2的X锁再尝试加id1的X锁形成循环二级索引加锁导致的聚簇索引锁竞争二级索引加锁后会同步锁定聚簇索引的对应记录若多事务对不同的二级索引记录加锁且对应的聚簇索引记录交叉易引发死锁间隙锁的范围过大非唯一索引的等值查询Next-Key Lock锁定的范围过大导致不同事务的锁区间交叉形成死锁。
死锁的解决与预防策略统一加锁顺序所有事务对多个行加锁时遵循相同的索引顺序如按主键升序加锁从根源上避免循环等待减少加锁范围尽量使用唯一索引的精准等值查询让Next-Key Lock退化为Record Lock减小锁粒度避免非必要的范围查询减少间隙锁的锁定范围缩短事务时长尽量让事务“快进快出”减少锁的持有时间降低锁冲突的概率避免在事务中执行无关的操作如IO、网络请求利用InnoDB的死锁检测机制InnoDB会自动检测死锁当检测到死锁时会主动回滚持有锁最少的事务代价最小原则释放锁资源也可通过innodb_deadlock_detect参数开启/关闭死锁检测高并发场景下若死锁频繁可暂时关闭改为通过innodb_lock_wait_timeout设置锁等待超时避免长事务长事务会持续持有锁导致其他事务长时间等待极易引发死锁生产中需严格控制长事务的存在。
2 锁等待事务持有锁其他事务等待锁释放锁等待是指一个事务持有某把锁另一个事务尝试加同一把互斥的锁只能等待该锁释放若等待时间过长会触发锁等待超时。
锁等待比死锁更常见会导致业务响应缓慢甚至超时。
锁等待的常见触发原因无索引导致行级锁升级为表级锁引发全表锁阻塞非唯一索引的等值/范围查询Next-Key Lock锁定范围过大导致无关行被阻塞长事务持续持有锁锁的持有时间过长幻读防护导致的间隙锁阻塞非必要的间隙锁锁定了插入操作。
锁等待的优化策略为所有加锁操作的查询条件建立索引这是最核心的优化手段保证InnoDB能使用行级锁避免升级为表级锁尽量使用唯一索引唯一索引的精准等值查询能让Next-Key Lock退化为Record Lock减小锁粒度减少阻塞优化查询条件避免非必要的范围查询尽量使用精准等值查询减少间隙锁的使用控制事务粒度让事务仅包含必要的操作缩短锁的持有时间合理设置隔离级别若业务能容忍幻读可将部分事务的隔离级别改为RC避免间隙锁和Next-Key Lock的阻塞提升并发性能监控锁等待情况通过MySQL的系统表information_schema.innodb_locks、information_schema.innodb_lock_waits监控锁等待的情况定位锁等待的源头及时优化。
前瞻性思考高并发趋势下MySQL锁机制的优化方向与实践建议随着互联网业务的高速发展高并发、大数据量成为MySQL的主流应用场景对锁机制的性能和灵活性提出了更高的要求。
结合InnoDB的发展趋势和高并发业务的特点给出以下锁机制的优化方向与实践建议帮助开发者提前布局应对未来的业务挑战。
1 隔离级别精细化按需选择RC/RR平衡一致性与并发InnoDB的默认隔离级别是RR但并非所有业务都需要彻底解决幻读很多读多写少的业务能容忍轻微的幻读此时可将事务的隔离级别改为RC避免间隙锁和Next-Key Lock的使用大幅提升并发性能。
实践建议采用隔离级别精细化配置核心交易业务如支付、订单使用RR保证数据强一致性非核心业务如日志、统计使用RC提升并发性能。
可通过SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;为单个会话设置隔离级别避免全局修改影响核心业务。
2 利用MVCC实现“无锁读”减少锁的使用InnoDB的MVCC多版本并发控制与锁机制相辅相成MVCC实现了“快照读”——普通的SELECT操作不加锁通过读取数据的快照版本避免了读操作阻塞写操作这是InnoDB高并发的核心设计。
实践建议尽量使用普通SELECT的无锁读避免非必要的显式加锁如LOCK IN SHARE MODE只有在需要保证读操作一致性的场景如多事务协同操作才使用显式加锁的读操作减少锁的竞争。
3 结合分布式锁解决跨库/跨表的锁问题随着业务的发展单库单表已无法满足需求分库分表成为主流此时MySQL的行级锁/表级锁无法解决跨库/跨表的并发冲突需要结合分布式锁如Redis分布式锁、ZooKeeper分布式锁。
实践建议单库单表内的并发冲突使用MySQL自身的锁机制跨库/跨表的并发冲突结合分布式锁实现全局的资源控制注意分布式锁与MySQL锁的协同避免双重锁阻塞同时保证分布式锁的原子性和超时释放。
4 关注InnoDB的锁机制升级自适应哈希索引、锁优化InnoDB一直在持续优化锁机制如自适应哈希索引AHI能提升索引的查询效率减少锁的持有时间InnoDB
0中对间隙锁做了优化减少了非必要的间隙锁锁定同时InnoDB对死锁检测、锁等待的处理也做了大量改进。
实践建议及时升级MySQL版本优先使用InnoDB
0及以上版本享受锁机制的优化成果合理开启自适应哈希索引innodb_adaptive_hash_index提升高并发下的索引查询效率减少锁冲突。
5 读写分离与分库分表从架构层面减少锁竞争锁机制的优化是“治标”而架构层面的优化是“治本”读写分离和分库分表能从根源上减少锁的竞争读写分离将读操作分流到从库主库仅处理写操作减少主库的锁竞争分库分表将数据分散到多个库/表每个库/表的并发量大幅降低锁冲突的概率也随之降低实践建议当单库的并发量达到瓶颈时及时引入读写分离当单表的数据量超过千万级时及时进行分库分表结合哈希分表、范围分表等方式让数据均匀分布减少单表的锁竞争。
八、
总结吃透锁机制是高并发MySQL开发的核心能力MySQL的锁机制是一套从基础到复杂、从粗粒度到细粒度的完整体系其核心逻辑可
总结为以S/X锁为二元基础以索引为行级锁的实现前提以隔离级别为锁策略的控制依据以Record Lock和Gap Lock为细分以Next-Key Lock为终极方案以意向锁为辅助协调最终实现了数据一致性与并发性能的平衡。
对于开发者而言吃透锁机制的底层逻辑不仅能解决生产中的死锁、锁等待、幻读等问题更能在高并发场景下设计出更合理的数据库操作方案从根源上减少锁冲突。
核心要点可归纳为行级锁依赖索引无索引必升级为表级锁这是所有锁优化的基础RR隔离级别通过Next-Key Lock彻底解决幻读且会按需退化为Record Lock/Gap Lock兼顾性能与一致性间隙锁仅在RR生效是解决幻读的关键也是锁阻塞的常见原因死锁的核心解决思路是统一加锁顺序、减少锁范围、缩短事务时长高并发场景下需结合架构优化读写分离、分库分表和锁机制优化从根源上减少锁竞争。
在高并发成为主流的今天MySQL的锁机制仍在持续发展而理解其底层逻辑是应对所有变化的核心能力。
只有真正吃透锁机制才能让MySQL在高并发业务中发挥出最大的性能同时保障数据的一致性。