MySQL作为最常用的关系型数据库之一，其并发控制能力高度依赖锁机制。不同的锁类型和加锁过程会显著影响多事务同时访问数据时的性能表现。理解这些概念，是设计高并发系统和排查线上故障的基础。
一、MySQL中常见的锁类型
在InnoDB存储引擎里，锁可以从多个维度划分。按照粒度可分为全局锁、表级锁和行级锁；按照功能意图可分为共享锁、排他锁以及意向锁；按照算法又包含记录锁、间隙锁和next-key锁。每种锁的适用场景和开销都不相同，错误使用会导致严重的阻塞。
共享锁（S锁）允许事务读取一行数据，多个事务可同时持有。排他锁（X锁）则用于修改，同一时刻只能有一个事务持有。InnoDB在获取行锁之前，会先对表加意向锁（IS或IX），这是一种轻量级的标记，用于快速判断表级冲突，避免逐行检查。
-- 对指定行加共享锁 SELECT * FROM user WHERE id = 1 LOCK IN SHARE MODE; -- 对指定行加排他锁 SELECT * FROM user WHERE id = 1 FOR UPDATE; -- 查看当前锁等待情况 SELECT * FROM information_schema.INNODB_LOCKS;
1.1 记录锁、间隙锁与next-key锁
记录锁只锁住已存在的索引记录；间隙锁锁住两条记录之间的空隙，防止其他事务插入；next-key锁是记录锁加间隙锁的组合，也是InnoDB在可重复读级别下的默认行锁算法。它通过锁定一个左开右闭的区间，解决了幻读问题。
例如，当表中已有id为10和20的记录，执行WHERE id > 10 AND id < 20 FOR UPDATE时，InnoDB会对(10,20)这个间隙加锁，阻止新插入id为15的数据。这种机制虽保证了一致性，但也可能成为并发插入的瓶颈。
二、加锁过程是如何执行的
加锁并非随意进行，而是严格依赖SQL语句的执行计划和索引结构。当一条UPDATE或SELECT ... FOR UPDATE语句发起时，MySQL优化器先决定使用哪个索引，存储引擎沿着索引树定位目标记录，再在对应的索引项上加锁。
如果查询没有命中索引，InnoDB无法精准定位行，就会退化为全表扫描，并对扫描过的每一行加next-key锁，实质上接近表锁。这也是为什么线上常因缺失索引导致整张表被锁住，引发雪崩式超时。
-- 假设user表在name字段无索引 UPDATE user SET age = 20 WHERE name = 'tom'; -- 上述语句会锁住表中绝大多数行，直到事务结束 -- 添加索引后，仅锁定匹配name='tom'的行 ALTER TABLE user ADD INDEX idx_name (name);
2.1 两阶段锁协议
InnoDB遵循两阶段锁协议：事务执行期间不断加锁，直到提交或回滚时才统一释放。这意味着锁的持有时间往往覆盖整个事务，而非单条语句。因此，把更新频繁的操作放在事务末尾，能有效缩短锁占用窗口。
此外，死锁检测机制会在发现循环等待时，主动回滚代价较小的事务。开发者应通过固定访问顺序、降低事务粒度来规避死锁，而不是依赖数据库频繁回滚。
三、锁对并发性能的实际影响
锁的存在天然引入串行化点。行锁粒度细，并发度高，但管理成本高；表锁开销小，却严重限制并发。在读写混合场景中，不必要的排他锁会让后续读请求堆积，连接数飙升，CPU消耗在锁等待而非业务逻辑上。
通过监控innodb_row_lock_waits和innodb_row_lock_time_avg等指标，可以量化锁竞争。当发现平均等待时间持续增长，应优先审查事务设计和索引覆盖情况，而非简单扩容数据库。
| 锁类型 | 并发度 | 典型开销 | 适用场景 |
|---|---|---|---|
| 表锁 | 低 | 极小 | 全表批量操作 |
| 行锁 | 高 | 中等 | 高并发OLTP |
| 间隙锁 | 中 | 中等 | 防止幻读 |
3.1 减少锁冲突的实践建议
首先，所有频繁更新的查询必须走索引，避免锁升级。其次，控制事务大小，不在事务内调用远程接口或执行慢查询。最后，读多写少场景可考虑使用多版本并发控制带来的非锁读，即普通SELECT不加锁，依赖Undo日志获取快照。
当业务允许时，适当降低隔离级别到读已提交，能减少间隙锁的使用，从而提升插入并发。但需自行处理幻读风险，属于架构上的权衡。
锁机制是MySQL保障数据一致性的核心，但也是并发性能的关键制约。理清锁类型与加锁路径，才能写出既安全又高效的SQL。
四、总结
从锁的分类到加锁过程，再到并发影响，MySQL的锁体系环环相扣。开发阶段就应设想高并发下的锁行为，借助执行计划确认索引命中，并尽量缩短事务生命周期。只有将锁认知融入日常建模与编码，系统才会在流量增长时依然平稳。