本文共 1423 字，大约阅读时间需要 4 分钟。
MySQL 锁的实现方式根据不同的隔离级别有所不同，而默认的隔离级别是 repeatable-read（可重复读）。在实际应用中，许多开发者对 MySQL 锁的具体实现机制不够清晰，尤其是不同隔离级别下锁的行为差异。以下将从 repeatable-read 隔离级别出发，结合实际操作结果，分析 MySQL 行锁的实现方式。
首先，我们创建了一个简单的测试表 t1，并插入部分数据。表 t1 的主键是 id，并且索引 age1 被创建。以下是表的创建语句和初始数据：
CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `age1` int(11) DEFAULT NULL, `age2` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `age1` (`age1`)) ENGINE=InnoDB;
随后，我们在两个不同的 session 中执行了多个更新操作，观察锁的行为。以下是操作的具体步骤：
Session 1:
BEGIN;UPDATE t1 SET age2 = 55 WHERE age1 = 1 AND id = 2;COMMIT;
Session 2:
BEGIN;UPDATE t1 SET age2 = 55 WHERE age1 = 1 AND id = 3;COMMIT;
初始操作显示没有问题，锁机制正常工作。
接下来，我们尝试进一步测试锁的行为：
Session 1:
BEGIN;UPDATE t1 SET age2 = 55 WHERE age1 = 1 AND age2 = 4;COMMIT;
Session 2:
BEGIN;UPDATE t1 SET age2 = 55 WHERE age1 = 1 AND id = 1;COMMIT;
此时，Session 2 执行了一个更新操作，结果出现了 Lock wait timeout exceeded 错误，提示锁等待超时。进一步查看 innodb_lock_waits 表，发现 Session 2 在等待 t1 表的 PRIMARY 索引上的 X 锁。
为了更深入理解锁的行为，我们还尝试了插入操作：
Session 1:
BEGIN;INSERT INTO t1 (age1, age2) VALUES (1, 33);COMMIT;
Session 2:
BEGIN;UPDATE t1 SET age2 = 55 WHERE age1 = 2;COMMIT;
同样地，Session 2 执行更新操作时，Session 1 执行插入操作也出现了锁等待超时。通过分析 innodb_lock_waits 表，可以看到插入操作等待的是 age1 索引上的 X 锁，并且锁等待模式为 GAP（可能与插入操作相关的锁机制有关）。
通过上述测试，我们可以看出 MySQL 在 repeatable-read 隔离级别下，行锁机制确实是通过索引实现的。具体来说，行锁是通过记录锁（record lock）来实现的，而索引的存在显著提升了锁的获取效率。
在实际应用中，了解 MySQL 锁的实现机制对于优化数据库性能至关重要。特别是在多个 session 并发操作时，合理设计索引和隔离级别，可以有效避免锁等待问题。
转载地址：http://dwbfk.baihongyu.com/