1. 行级锁的本质与分类MySQL的行级锁是InnoDB引擎实现并发控制的核心机制。与表锁不同行级锁可以精确锁定数据行大幅提升并发性能。但很多开发者对它的加锁规则存在误解。1.1 记录锁Record Lock记录锁是最基础的行锁类型直接锁定索引记录。当执行SELECT ... FOR UPDATE或UPDATE语句时InnoDB会在符合条件的索引记录上加锁。这里有个关键细节记录锁实际上是加在索引上的而不是数据行本身。比如执行UPDATE users SET name张三 WHERE id10;如果id是主键InnoDB会在主键索引的id10这条记录上加X锁。如果没有合适索引InnoDB会退化为表锁。1.2 间隙锁Gap Lock间隙锁锁定的是索引记录之间的间隙防止其他事务在这个范围内插入数据。这是InnoDB解决幻读问题的主要手段。典型场景是范围查询SELECT * FROM users WHERE age BETWEEN 20 AND 30 FOR UPDATE;这个查询不仅会锁定age在20-30之间的现有记录还会锁定(20,30)这个区间阻止其他事务插入age25的新记录。1.3 临键锁Next-Key Lock临键锁是记录锁和间隙锁的组合锁定记录本身以及前面的间隙。这是InnoDB默认的行锁算法。例如索引有值10,20,30锁定记录20的临键锁会锁定(10,20]这个区间这种设计既防止了幻读又避免了丢失更新1.4 插入意向锁Insert Intention Lock这是一种特殊的间隙锁表示事务准备在某个间隙插入记录。多个事务可以在同一个间隙上持有兼容的插入意向锁但会与已有的间隙锁冲突。2. 加锁的核心规则解析2.1 索引类型决定加锁方式InnoDB的加锁行为与索引使用密切相关主键/唯一索引查询UPDATE table SET colval WHERE primary_key1;只会在主键1的记录上加X锁普通索引查询UPDATE table SET colval WHERE secondary_index2;会先在二级索引上加X锁然后通过回表在主键索引上加锁无索引查询UPDATE table SET colval WHERE no_index_col3;会导致全表扫描给所有记录加锁最终退化为表锁提示务必为高频查询条件建立合适索引避免锁升级2.2 隔离级别的影响不同隔离级别下锁行为差异很大隔离级别脏读不可重复读幻读加锁特点READ UNCOMMITTED可能可能可能不加锁READ COMMITTED不可能可能可能只加记录锁REPEATABLE READ不可能不可能可能默认加临键锁SERIALIZABLE不可能不可能不可能所有读操作都加共享锁MySQL默认使用REPEATABLE READ这也是为什么默认会加临键锁防止幻读。2.3 不同SQL语句的加锁策略SELECT ... FOR UPDATE对扫描到的索引记录加X锁如果使用唯一索引且精确匹配只锁单行否则可能锁多行或间隙UPDATE/DELETE与SELECT FOR UPDATE类似如果修改了索引列会导致索引变更可能引发更多锁INSERT会在插入的索引记录上加排他锁会检查插入意向锁是否与已有间隙锁冲突3. 实战中的加锁案例分析3.1 主键查询场景-- 事务1 BEGIN; SELECT * FROM accounts WHERE account_id 1 FOR UPDATE; -- 事务2 BEGIN; SELECT * FROM accounts WHERE account_id 1 FOR UPDATE; -- 阻塞这里事务2会被阻塞因为事务1已经在account_id1的主键记录上加了X锁。3.2 非唯一索引场景假设有表CREATE TABLE orders ( id int PRIMARY KEY, user_id int, KEY idx_user (user_id) );执行-- 事务1 BEGIN; SELECT * FROM orders WHERE user_id 100 FOR UPDATE; -- 事务2 BEGIN; INSERT INTO orders VALUES (5, 100); -- 可能被阻塞事务1在user_id100的所有记录上加锁同时会锁定user_id100前后的间隙。事务2的插入操作可能因间隙锁而阻塞。3.3 范围查询场景-- 事务1 BEGIN; SELECT * FROM accounts WHERE balance BETWEEN 1000 AND 2000 FOR UPDATE; -- 事务2 BEGIN; INSERT INTO accounts (balance) VALUES (1500); -- 被阻塞事务1锁定了balance在1000-2000之间的所有记录和间隙事务2的插入操作会被阻塞。4. 锁冲突与死锁问题4.1 常见锁冲突场景交叉更新-- 事务1 UPDATE accounts SET balance balance - 100 WHERE id 1; UPDATE accounts SET balance balance 100 WHERE id 2; -- 事务2 UPDATE accounts SET balance balance - 50 WHERE id 2; UPDATE accounts SET balance balance 50 WHERE id 1;这种交叉更新顺序很容易导致死锁。间隙锁冲突-- 事务1 SELECT * FROM accounts WHERE age 20 FOR UPDATE; -- 事务2 INSERT INTO accounts (age) VALUES (25); -- 被阻塞4.2 死锁分析与解决当发生死锁时MySQL会自动检测并回滚其中一个事务。可以通过以下方式排查查看死锁日志SHOW ENGINE INNODB STATUS;在输出的LATEST DETECTED DEADLOCK部分可以看到详细死锁信息。预防死锁的最佳实践保持事务短小精悍按照固定顺序访问多行数据合理设计索引减少锁范围必要时使用SELECT ... FOR UPDATE NOWAIT5. 性能优化与监控5.1 锁等待调优设置锁等待超时SET innodb_lock_wait_timeout 30; -- 单位秒监控锁等待-- 查看当前锁等待 SELECT * FROM performance_schema.events_waits_current WHERE EVENT_NAME LIKE %lock%; -- 查看锁统计 SELECT * FROM sys.innodb_lock_waits;5.2 减少锁竞争的方法索引优化确保查询使用合适的索引避免全表扫描事务设计减小事务粒度避免长事务考虑使用乐观锁架构层面读写分离分库分表使用缓存减少数据库压力6. 特殊场景下的锁行为6.1 外键约束的加锁外键约束会导致额外的锁当插入子表记录时会在父表对应记录上加S锁当删除/更新父表记录时会检查子表是否有对应记录6.2 唯一键冲突当插入记录导致唯一键冲突时会在冲突的唯一索引上加S锁这可能导致其他事务的插入操作被阻塞6.3 自增锁自增列使用特殊的表级锁AUTO-INC锁在语句执行期间持有不是事务期间可以配置innodb_autoinc_lock_mode改变行为7. 锁的内部实现机制7.1 锁的内存结构InnoDB使用锁管理器维护锁信息每个锁包含事务ID、索引信息、锁类型等锁信息存储在内存中通过哈希表快速查找7.2 锁的升级与转换InnoDB会根据情况自动进行锁转换当扫描大量记录时可能将行锁升级为表锁在某些条件下间隙锁可能转换为记录锁7.3 锁的释放时机锁的释放发生在事务提交或回滚时当不再需要锁时如语句执行完成但在REPEATABLE READ隔离级别下锁会持有到事务结束。