当前位置：首页 > news >正文

MySQL锁机制详解！

news 来源：原创 2025/5/9 11:33:41

在这里插入图片描述

- 前言
- 一、为什么需要锁？——并发的“四大恶人”
- 二、锁的“地盘”——锁的粒度
- 三、锁的“性质”——锁的类型
- 四、InnoDB 的秘密武器：MVCC
- 五、代码演示：锁的爱恨情仇
- 六、如何窥探锁的内部世界？
- 七、如何驯服锁这匹野马？——锁的优化与实践
- 八、总结：锁，是并发世界的秩序

🌟我的其他文章也讲解的比较有趣😁，如果喜欢博主的讲解方式，可以多多支持一下，感谢🤗！

其他优质专栏：【🎇SpringBoot】【🎉多线程】【🎨Redis】【✨设计模式专栏（已完结）】…等

如果喜欢作者的讲解方式，可以点赞收藏加关注，你的支持就是我的动力
✨更多文章请看个人主页：码熔burning

前言

好的，各位技术同僚们！😎 大家好！

今天，作为一名幽默的程序员，咱们来聊聊一个让无数工程师“又爱又恨”、“摸不透看不懂但又离不开”的老伙计——MySQL的锁机制。

话说，数据库这玩意儿，就像一个超大的公共图书馆，里面藏着无数珍贵的书籍（数据）。📚 如果只有你一个人在里面看书写字，那简直是天堂！爱怎么翻怎么翻，爱怎么涂改怎么涂改（别真涂改啊喂！）。

但现实是残酷的！图书馆里永远挤满了人（高并发！）。想象一下，你正在专心致志地阅读《葵花宝典》（某个重要数据），结果旁边来了个哥们儿，直接把书抽走了要写笔记；或者更糟，他直接把书撕了要改内容！😱 这不天下大乱了吗？

为了维护这个图书馆的秩序，防止大家互相踩踏、抢书、毁书，我们就需要一个强有力的“图书管理员兼保安队伍”——锁机制！🔒

锁，简单来说，就是一种控制并发访问数据库资源的机制。它规定了在某个时间点，哪些操作可以进行，哪些必须等待。理解锁，就是理解如何在并发世界里，让你的数据操作既高效又不翻车。

一、为什么需要锁？——并发的“四大恶人”

在没有锁或者锁使用不当的情况下，并发操作可能会导致一些让人头疼的问题，就像图书馆里的“四大恶人”：

脏读 (Dirty Read): 😈 一个事务读到了另一个事务还未提交的数据。就像你读了一份草稿，结果写草稿的人发现写错了，把那段划掉了，你读的内容瞬间就成了“废话”。如果基于这个废话做了决策，后果不堪设想！
- 场景模拟：
  - Session 1：START TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE user_id = 1; (用户1余额扣了100，但还没提交)
  - Session 2：SELECT balance FROM accounts WHERE user_id = 1; (读到了用户1扣了100后的临时余额)
  - Session 1：ROLLBACK; (用户1的余额回滚到扣款前)
  - Session 2：基于刚才读到的临时余额做了别的操作… Ouch! 💥
不可重复读 (Non-Repeatable Read): 👻 一个事务在同一个查询中，两次读取同一条记录，结果发现数据变了。就像你第一次看《葵花宝典》是修订版A，第二次看发现它变成了修订版B。不是说好了“重复”读吗？怎么不一样了？！这通常是由于另一个已提交的事务修改了数据。
- 场景模拟：
  - Session 1：START TRANSACTION; SELECT balance FROM accounts WHERE user_id = 1; (第一次读，余额1000)
  - Session 2：UPDATE accounts SET balance = balance + 200 WHERE user_id = 1; COMMIT; (另一个事务提交了修改)
  - Session 1：SELECT balance FROM accounts WHERE user_id = 1; (第二次读，余额1200)
  - Session 1：🤯 等等，我没看错吧？
幻读 (Phantom Read): 👽 一个事务在同一个范围查询中，两次查询的结果集发现记录数变了（多了或少了）。就像你第一次统计图书馆里“武侠类”书籍有100本，第二次统计发现变成了105本，多了5本“幽灵”书籍！这是由于另一个已提交的事务插入或删除了符合查询条件的数据。
- 场景模拟：
  - Session 1：START TRANSACTION; SELECT COUNT(*) FROM orders WHERE status = 'pending'; (查到10个待处理订单)
  - Session 2：INSERT INTO orders (status, ...) VALUES ('pending', ...); COMMIT; (另一个事务插入了一个新的待处理订单)
  - Session 1：SELECT COUNT(*) FROM orders WHERE status = 'pending'; (查到11个待处理订单)
  - Session 1：哪里来的第11个订单？刚才明明只有10个！😱 这不是鬼打墙吗？
更新丢失 (Lost Update): 💀 两个事务同时修改同一份数据，一个事务的修改覆盖了另一个事务的修改，导致其中一个修改“丢失”了。
- 场景模拟：
  - Session 1：SELECT balance FROM accounts WHERE user_id = 1; (读到余额1000)
  - Session 2：SELECT balance FROM accounts WHERE user_id = 1; (也读到余额1000)
  - Session 1：UPDATE accounts SET balance = balance - 100 WHERE user_id = 1; COMMIT; (将余额更新为900)
  - Session 2：UPDATE accounts SET balance = balance + 200 WHERE user_id = 1; COMMIT; (将余额更新为 1000 + 200 = 1200)
  - 结果：Session 1 的 -100 操作丢失了，最终余额是1200，而不是 1000 - 100 + 200 = 1100。这比脏读更隐蔽，因为两个事务都提交了！

为了防止这些“恶人”捣乱，锁机制应运而生！它是维护数据一致性和隔离性的基石。

二、锁的“地盘”——锁的粒度

锁不是随便加的，加锁也是有成本的。锁住的范围越大，并发性越差；锁住的范围越小，并发性越好，但锁的管理开销越大。MySQL根据不同的需求，提供了不同“地盘”的锁：

全局锁 (Global Lock): 🌍 这是最大层级的锁，直接把整个数据库实例给锁住了！一旦加了全局锁，别的线程就只能读，不能写，也不能修改结构（DDL）。就像把整个图书馆大门焊死了，大家只能在门口看看书名，不能进去翻阅或借还。
- 典型用途：做全库逻辑备份（比如 mysqldump --single-transaction 在 InnoDB 下不会加全局锁，但如果涉及到 MyISAM 等存储引擎就需要）。
- 命令：FLUSH TABLES WITH READ LOCK;
- 释放：UNLOCK TABLES; 或客户端断开连接。
- 幽默解读：“各位，今天图书馆搞卫生，全馆暂停一切业务！除了保安大叔（备份工具）可以在里面溜达溜达。”
表级锁 (Table Lock): 🚪 比全局锁小一点，只锁住当前的表。这就像锁住了图书馆里的“武侠区”房间，其他房间（其他表）还能正常使用。
- MySQL 里 MyISAM 存储引擎默认就是表级锁：任何对表的读写操作，都会先加表锁。想想看，如果一张表很多人读，一个人写，写的人就得等所有读的人完成；如果一个人写，所有读的人也得等着。并发性非常差！所以 MyISAM 已经逐渐被淘汰了。
- InnoDB 也有表级锁，但通常是 MySQL 内部使用的：比如 ALTER TABLE 操作会加表锁。
- 我们也可以手动加：LOCK TABLES table_name READ; (读锁) 或 LOCK TABLES table_name WRITE; (写锁)。手动加表锁是需要谨慎的！
- 释放：UNLOCK TABLES; 或客户端断开。
- 幽默解读：MyISAM 说：“简单好！要么大家一起读（共享），要么我一个人写（独占）！效率嘛… 咱不提那茬！” InnoDB 手动表锁：“非必要不打扰，打扰就是干票大的（DDL）！”
页级锁 (Page Lock): 📄 介于表锁和行锁之间，一次锁住一页数据。BDB 存储引擎支持页级锁，但 BDB 也不常用。这个咱们了解一下就好，就像图书馆里按“书架层”来锁，一次锁一层书。
行级锁 (Row Lock): 🚶‍♂️ 这是 InnoDB 存储引擎的王牌！也是最常用、最精细的锁。它只锁住需要操作的一行或几行数据。这就像图书馆里你只锁住你正在看的那本书，旁边的人可以继续看别的书，甚至可以看同一本书的不同页（如果实现了 MVCC 的话 😉）。
- 优点：最大程度支持并发，多个事务可以同时访问同一张表的不同行。
- 缺点：锁的管理开销比较大，需要对每一行数据进行加锁/解锁操作。
- 幽默解读：InnoDB 行锁：“来来来，各看各的！只要不是同一本书（同一行）的同一页（同一修改），随便看！即使是同一页，如果你只是看，我也可能让你进来（MVCC）！”

三、锁的“性质”——锁的类型

光有地盘还不够，锁还得有不同的“性质”，比如是允许大家一起看（共享），还是只能一个人独占修改。

共享锁 (Shared Lock, S Lock): 🤝 允许事务读（SELECT）一行数据。多个事务可以同时对同一行数据加 S 锁。就像多人可以同时阅读同一本书，互不影响。
- 获取方式：SELECT ... FOR SHARE; (在可重复读或读已提交隔离级别下显式加 S 锁)
- 兼容性：S 锁与 S 锁兼容，但与 X 锁互斥。
排他锁 (Exclusive Lock, X Lock): ⚔️ 允许事务修改（INSERT, UPDATE, DELETE）一行数据。一旦对一行数据加了 X 锁，其他任何事务都不能再对这行数据加任何锁（S 锁或 X 锁），直到 X 锁释放。就像一个人占用了书桌要写笔记，其他人只能等着。
- 获取方式：INSERT, UPDATE, DELETE 操作会自动对涉及的行加 X 锁；SELECT ... FOR UPDATE; (显式加 X 锁)
- 兼容性：X 锁与任何锁都不兼容（除了意向锁）。

重要的兼容性矩阵 (Lock Compatibility Matrix):

想加的锁 \ 已有的锁	None	S	X	IS	IX
S	Yes	Yes	No	Yes	No
X	Yes	No	No	No	No
IS	Yes	Yes	Yes	Yes	Yes
IX	Yes	No	No	Yes	Yes

Yes: 兼容，可以同时持有。
No: 不兼容，想加锁的事务需要等待已持有锁的事务释放锁。
幽默解读：S vs S：“都是来看书的，坐！随便坐！” S vs X：“你是来看，我是来改，我们俩不对付，你等我改完！” X vs X：“都是来改的？对不起，今天只接待一位！” 意向锁后面讲。

意向锁 (Intention Locks, IS/IX): 🤔 这是一个表级的锁，但在 InnoDB 里用来协调表锁和行锁。听起来有点绕？别急，它的作用是：告诉其他事务，我（当前事务）打算在表中的某些行上加行锁！
- 意向共享锁 (IS Lock): 事务打算在表中的某些行上加 S 锁。
- 意向排他锁 (IX Lock): 事务打算在表中的某些行上加 X 锁。
- 获取方式：当一个事务需要对表中的某行加 S 锁时，会先对该表加 IS 锁；需要对表中的某行加 X 锁时，会先对该表加 IX 锁。这些都是由 InnoDB 自动管理的，我们通常感知不到。
- 为什么需要意向锁？ 设想一下，如果没有意向锁，一个事务想对整张表加 X 表锁进行维护（比如 ALTER TABLE）。它怎么知道有没有其他事务正在对某一行加行锁呢？它难道要遍历检查所有行吗？效率太低了！
  有了意向锁就简单了：如果表上已经有 IS 或 IX 锁，就说明有事务正在搞行锁，要加 X 表锁的事务就不能立即获取，必须等待意向锁释放。反过来，如果一个事务想加行锁，发现表上已经有 X 表锁了，那也别想加行锁了，直接等。
- 兼容性：意向锁之间是互相兼容的（IS 和 IX 可以共存），并且它们只与表级的 S 锁和 X 锁互斥。注意看上面的兼容性矩阵，IS 和 IX 和 S、X 是有互斥关系的，但它们自己内部以及与 S、X 的行锁不互斥。
- 幽默解读：意向锁就像在图书馆门口挂个牌子：“注意啦！我（事务）要进去了，准备在里面某个地方看书（IS）/写字（IX）了！” 门口想锁整个馆（表级锁）的保安（其他事务）看到牌子就知道里面有人了，不能直接锁。在里面搞行锁的人（当前事务）自己挂个牌子，也不影响其他人在其他地方搞行锁。
记录锁 (Record Lock): 🔑 这是最基础的行锁，锁住的是索引记录。如果你的查询没有用到索引，InnoDB 可能会退化到全表扫描并对所有记录加行锁，那并发性就惨了！
- 幽默解读：锁住的是“索引卡片”，而不是书本身。如果书没有索引卡片，就得把所有卡片都翻一遍！
间隙锁 (Gap Lock): 🥅 锁住索引记录之间的“间隙”，或者锁住第一个索引记录之前的间隙，或最后一个索引记录之后的间隙。它的作用是防止幻读！它只阻止其他事务插入数据到这个间隙中。
- 场景：如果你查询 SELECT * FROM users WHERE age BETWEEN 18 AND 30; 并且 age 字段有索引，InnoDB 可能会给这个范围内的索引记录以及它们之间的“空隙”加间隙锁。这样，在你的事务提交前，其他事务就无法插入一个新的 age 在 18 到 30 之间的用户。
- 注意：间隙锁不锁记录本身，所以两个事务可以对同一个间隙加间隙锁。间隙锁的目的是阻止插入，而不是修改或删除现有记录。
- 幽默解读：就像图书馆里，你不仅守着你看的那本书，还在你和下一本书之间拉了一条警戒线，不让人往这个位置塞新书！
临键锁 (Next-Key Lock): 🗝️ 这是 InnoDB 默认的行锁类型，在 REPEATABLE READ 事务隔离级别下使用。它实际上是记录锁和间隙锁的组合！它锁住一个索引记录以及该记录之前的间隙。
- 范围：(前一个索引记录, 当前索引记录] （左开右闭区间）。对于最后一个索引记录，是 (最后一个索引记录, +inf)。对于没有索引的列，或没有符合条件的记录，可能会锁住整个扫描范围或全表。
- 作用：同时解决了不可重复读（通过记录锁）和幻读（通过间隙锁）。
- 幽默解读：临键锁是间隙锁和记录锁的合体金刚！不仅守着书，还把书前面的空位也守住了！“这片区域（间隙）和这本宝贝书（记录），都是我的地盘！谁也别想动！”
插入意向锁 (Insert Intention Lock): 🚦 这个锁比较特殊，只发生在 INSERT 操作之前。当多个事务同时插入数据到同一个间隙中时，它们都会在该间隙加上一个插入意向锁。
- 特点：多个事务可以在同一个间隙上拥有插入意向锁，因为它们插入的是不同的记录。但是，插入意向锁会互相阻塞，如果它们试图插入到完全相同的偏移位置（虽然在通常情况下插入是追加到间隙尾部，不会有这个问题）。
- 与间隙锁的关系：如果一个事务在一个间隙上持有间隙锁或临键锁，另一个事务想在这个间隙上插入数据，它就需要等待间隙锁/临键锁释放。插入意向锁表示的就是“我打算在这里插入”的状态，它与已有的间隙锁/临键锁是冲突的。
- 幽默解读：多个事务都在图书馆门口排队等着往“武侠区”某个空位塞新书。大家手里都拿着“我要塞书”的小纸条（插入意向锁）。只要空位够多且没人拉警戒线（间隙锁/临键锁），大家可以一起找空位塞。但如果有人拉了警戒线，那就都得等着。
AUTO-INC 锁: 🔢 专门针对自增长列（AUTO_INCREMENT）。它是一个特殊的表级锁，用于保证 AUTO_INCREMENT 值的唯一性和连续性。
- 策略：在插入数据时，获取这个锁，分配一个唯一的自增长值，然后释放锁。
- 优化：在 STATEMENT 格式的 binlog 下，这个锁可能会影响并发插入。InnoDB 有优化，对于简单的 INSERT 语句（可以预知插入行数），会使用一个轻量级的锁，在分配完 ID 后就释放，不影响其他事务插入。但对于像 INSERT ... SELECT 这样的复杂语句，仍然会使用表级的 AUTO-INC 锁。
- 幽默解读：负责给新来的书编号的老爷子，一次只给一本书编号，保证编号不重复。但如果一来一大批书（复杂 INSERT），他就得把桌子（表）占了，一本一本慢慢编。

四、InnoDB 的秘密武器：MVCC

聊锁不能不聊 MVCC！🤔 InnoDB 强大的并发能力，很大程度上归功于 MVCC。它不是锁，而是一种并发控制的方法，用来解决读写冲突。

深入了解MVCC请看：MVCC：多版本并发控制，让数据“时光倒流”的秘密！

MVCC 的核心思想是：读不加锁，读写不冲突。对于一般的 SELECT 查询（快照读），MVCC 会给事务一个数据快照，读到的数据是事务开始时的数据版本。即使其他事务在这期间修改并提交了数据，当前事务读到的仍然是旧版本的数据。这样，读操作就不会阻塞写操作，写操作也不会阻塞读操作。👍

原理简述：InnoDB 在每行记录后面默默地加了两个隐藏列：DB_TRX_ID (创建或最后一次修改该行的事务 ID) 和 DB_ROLL_PTR (指向 undo log 中该行上一个版本的指针)。SELECT 读取数据时，会根据事务 ID 和 undo log 构造出符合当前事务隔离级别要求的可见数据版本。
什么情况下会使用 MVCC (快照读)：普通的 SELECT 语句（不加锁的）。
什么情况下会使用锁 (当前读)：SELECT ... FOR SHARE; SELECT ... FOR UPDATE; INSERT, UPDATE, DELETE 语句。这些操作需要读到数据的最新版本，因此需要加锁来保证读写一致性。
幽默解读：MVCC 就像给每个事务发了一个“时间旅行相机”。你在某个时间点按下了快门（事务开始），之后你看到的都是这个时间点的景象，不管现实世界（其他事务）如何变化。但如果你要动手改造世界（更新/删除/加锁读），那就得回到“当前时间线”，乖乖排队（加锁）。

五、代码演示：锁的爱恨情仇

理论讲了一堆，来点实操！我们模拟两个客户端 Session，看看锁是怎么工作的。

假设我们有一个简单的 products 表：

CREATE TABLE products (id INT PRIMARY KEY AUTO_INCREMENT,name VARCHAR(100),stock INT
) ENGINE=InnoDB;INSERT INTO products (name, stock) VALUES ('Laptop', 100);
INSERT INTO products (name, stock) VALUES ('Mouse', 200);

场景一：S 锁与 X 锁的冲突

Session 1 (图书馆读者A): 想看看 Laptop 的库存，并锁定住，等会儿决定买不买。
Session 2 (图书馆读者B): 想看看 Laptop 的库存，也想锁定住，等会儿决定买不买。
Session 3 (图书馆管理员): 想修改 Laptop 的库存。

-- Session 1
START TRANSACTION;
SELECT stock FROM products WHERE name = 'Laptop' FOR SHARE; -- 加 S 锁
-- 此时，Session 1 持有 Laptop 这一行的 S 锁-- Session 2
START TRANSACTION;
SELECT stock FROM products WHERE name = 'Laptop' FOR SHARE; -- 尝试加 S 锁
-- 成功！S 锁与 S 锁兼容，Session 2 也可以获取 S 锁。
-- 此时，Session 1 和 Session 2 都持有 Laptop 这一行的 S 锁-- Session 3
START TRANSACTION;
UPDATE products SET stock = stock - 1 WHERE name = 'Laptop'; -- 尝试加 X 锁
-- 阻塞！Session 3 尝试对 Laptop 加 X 锁，但 Session 1 和 Session 2 持有 S 锁，S 与 X 不兼容。Session 3 进入等待状态。-- Session 1
COMMIT; -- 释放 S 锁-- Session 2
COMMIT; -- 释放 S 锁
-- Session 3 的 UPDATE 语句不再阻塞，可以获取 X 锁并执行。

幽默总结：两个读者都在看同一本书（S锁），互不影响。管理员想改书（X锁），发现有人在看，只好等等。读者看完走了，管理员才能动手。

场景二：X 锁与 X 锁的冲突

Session 1 (图书馆管理员A): 想修改 Laptop 的库存。
Session 2 (图书馆管理员B): 也想修改 Laptop 的库存。

-- Session 1
START TRANSACTION;
UPDATE products SET stock = stock - 1 WHERE name = 'Laptop'; -- 加 X 锁
-- 此时，Session 1 持有 Laptop 这一行的 X 锁-- Session 2
START TRANSACTION;
UPDATE products SET stock = stock + 5 WHERE name = 'Laptop'; -- 尝试加 X 锁
-- 阻塞！Session 2 尝试对 Laptop 加 X 锁，但 Session 1 持有 X 锁，X 与 X 不兼容。Session 2 进入等待状态。-- Session 1
COMMIT; -- 释放 X 锁
-- Session 2 的 UPDATE 语句不再阻塞，可以获取 X 锁并执行。

幽默总结：两个管理员都想动手改同一本书（X锁），只能一个一个来。先来的霸占着，后来的干瞪眼等着。

场景三：可怕的死锁 (Deadlock)

死锁就像两个固执的程序员，A 等着 B 释放资源，B 又等着 A 释放资源，结果谁也动不了，系统卡死了！🤯 MySQL 的 InnoDB 会自动检测死锁并选择一个事务作为“牺牲品”将其回滚，从而打破僵局。

Session 1 (事务A): 准备修改产品 Laptop，然后修改 Mouse。
Session 2 (事务B): 准备修改产品 Mouse，然后修改 Laptop。

-- Session 1
START TRANSACTION;
UPDATE products SET stock = stock - 1 WHERE name = 'Laptop'; -- A 锁住 Laptop (X锁)
-- 此时，Session 1 持有 Laptop 的 X 锁-- Session 2
START TRANSACTION;
UPDATE products SET stock = stock + 5 WHERE name = 'Mouse'; -- B 锁住 Mouse (X锁)
-- 此时，Session 2 持有 Mouse 的 X 锁-- Session 1
UPDATE products SET stock = stock - 1 WHERE name = 'Mouse'; -- A 尝试修改 Mouse，需要 Mouse 的 X 锁。
-- 阻塞！Mouse 的 X 锁被 Session 2 持有，Session 1 等待 Session 2。-- Session 2
UPDATE products SET stock = stock + 5 WHERE name = 'Laptop'; -- B 尝试修改 Laptop，需要 Laptop 的 X 锁。
-- 阻塞！Laptop 的 X 锁被 Session 1 持有，Session 2 等待 Session 1。-- 结果：Session 1 等待 Session 2，Session 2 等待 Session 1。死锁发生！
-- MySQL 会检测到死锁，并选择其中一个事务（比如 Session 2）进行回滚：
-- ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
-- Session 2 回滚，释放了 Mouse 的 X 锁。Session 1 获得 Mouse 的 X 锁，继续执行并提交。

幽默总结：A说：“把鼠标给我我就动！” B说：“你先把电脑给我我就动！” 两人僵持不下。最终，MySQL 里的“和事佬”看不过去了，一脚把其中一个踹飞（回滚），问题解决！死锁是并发编程的噩梦之一，排查起来尤其酸爽！😣

场景四：间隙锁和幻读 (在 REPEATABLE READ 隔离级别下)

假设我们的 products 表里只有 ‘Laptop’ (id=1, stock=100) 和 ‘Mouse’ (id=2, stock=200)。
我们在 REPEATABLE READ 隔离级别下进行演示。

-- Session 1 (隔离级别 REPEATABLE READ)
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT * FROM products WHERE id > 10; -- 查询 id 大于 10 的产品，目前没有。
-- 在 REPEATABLE READ 下，MySQL 会为这个范围 (10, +inf) 加间隙锁。-- Session 2
START TRANSACTION;
INSERT INTO products (name, stock) VALUES ('Keyboard', 300); -- id 会是 3
-- 成功！插入的 id 是 3，不在 Session 1 的间隙锁范围 (10, +inf) 内。-- Session 3
START TRANSACTION;
INSERT INTO products (name, stock) VALUES ('Monitor', 400); -- id 会是 4
-- 成功！插入的 id 是 4，不在 Session 1 的间隙锁范围 (10, +inf) 内。-- Session 4
START TRANSACTION;
INSERT INTO products (name, stock) VALUES ('Tablet', 500); -- id 会是 5
-- 成功！插入的 id 是 5，不在 Session 1 的间隙锁范围 (10, +inf) 内。-- Session 5
START TRANSACTION;
INSERT INTO products (name, stock) VALUES ('Speaker', 600); -- id 会是 6
-- 成功！插入的 id 是 6，不在 Session 1 的间隙锁范围 (10, +inf) 内。-- 现在我们来尝试插入一个 id 大于 10 的，比如 id=11
-- Session 6
START TRANSACTION;
INSERT INTO products (id, name, stock) VALUES (11, 'Webcam', 700);
-- 阻塞！Session 6 试图插入 id=11，这落入了 Session 1 持有的间隙锁 (10, +inf) 范围内，因此被阻塞。-- Session 1
SELECT * FROM products WHERE id > 10; -- 再次查询，结果仍然是空的，没有幻读。
-- 提交事务，释放间隙锁
COMMIT;-- Session 6 的 INSERT 不再阻塞，可以执行。
-- Session 6
COMMIT;

幽默总结：Session 1 想找“高富帅”（id > 10 的产品），发现一个没有，它还不满足，直接把“高富帅”可能出现的区域（id > 10 的所有未来位置）都圈起来（间隙锁），不让别人往里面塞新人。其他事务可以随便塞“矮穷矬”（id <= 10 的），但 Session 6 想塞个“高富帅”（id=11），对不起，区域被锁了，等等！

六、如何窥探锁的内部世界？

有时候，你的数据库突然变慢，或者请求被阻塞，很可能是锁的问题！这时候，你需要成为一名“锁侦探”，去看看谁在搞鬼。

SHOW ENGINE INNODB STATUS;: 这个命令非常强大，包含了 InnoDB 存储引擎的各种状态信息，其中就包括锁信息！
- 找 LATEST DETECTED DEADLOCK 部分，如果发生了死锁，这里会打印详细信息，包括哪些事务 involved，它们在等什么锁，持有什么锁。这简直是排查死锁的神器！
- 找 TRANSACTIONS 部分，这里列出了当前活跃的事务，包括它们的状态（比如 RUNNING, LOCK WAIT），以及它们持有的锁和正在等待的锁。这能帮你找到哪个事务被阻塞了，以及是谁阻塞了它。
- 幽默解读：这个命令就像撬开了 InnoDB 的“大脑”，里面各种混乱的信息流… 但仔细找找，总能发现一些“犯罪现场”的线索（死锁、阻塞）。
performance_schema: 这是 MySQL 5.5 引入的一个强大的诊断工具，提供了更细粒度的性能监控信息，包括锁。
- 你可以查询 performance_schema.data_locks 表，查看当前所有的锁信息。
- 你可以查询 performance_schema.data_lock_waits 表，查看当前所有的锁等待信息，清楚地知道哪个事务在等哪个事务释放锁。
```
-- 查看当前的锁
SELECTREQUESTING_ENGINE, REQUESTING_THREAD_ID, REQUESTING_EVENT_ID,REQUESTING_LOCK_ID, REQUESTING_TRANSACTION_ID,BLOCKING_ENGINE, BLOCKING_THREAD_ID, BLOCKING_EVENT_ID,BLOCKING_LOCK_ID, BLOCKING_TRANSACTION_ID
FROM performance_schema.data_lock_waits;-- 查看详细的锁信息
SELECT * FROM performance_schema.data_locks;
```
- 幽默解读：performance_schema 就像一个专业的监控中心，各种摄像头、传感器，能实时告诉你：“警报！Transaction X 正在等待 Transaction Y 的锁！位置是表 Z 的某一行！” 相比 SHOW ENGINE INNODB STATUS 的日记本，这个是实时地图和报告！

七、如何驯服锁这匹野马？——锁的优化与实践

理解锁是为了更好地使用和优化它。这里有一些实用的驯马技巧：

选择合适的事务隔离级别: 事务隔离级别越高，数据一致性越好，但并发性越差（加的锁越多，锁的时间越长）。
- READ UNCOMMITTED: 读到未提交数据（脏读），并发性最高，不安全，慎用！😈
- READ COMMITTED: 只能读到已提交数据，解决了脏读，但存在不可重复读和幻读。
- REPEATABLE READ (InnoDB 默认): 解决了脏读和不可重复读（通过 MVCC 和 Next-Key Lock），但仍可能存在幻读（在某些特殊情况下，比如跨事务 DDL）。这是 InnoDB 的默认级别，通常够用。
- SERIALIZABLE: 最高隔离级别，完全串行化，数据一致性最好，但并发性最差（读写都加锁）。相当于在图书馆门口立个牌子：“一个一个进！里面只能有一个人！” 💀
- 建议：多数情况下使用 InnoDB 默认的 REPEATABLE READ 即可。如果对数据一致性有极高要求，或者能接受低并发，可以考虑 SERIALIZABLE。如果追求极致并发且能接受少量脏读风险（比如统计报表），可以考虑 READ UNCOMMITTED (但通常不推荐！)。READ COMMITTED 在某些场景下（比如读多写少）也可能比 REPEATABLE READ 有更好的性能，因为它不使用间隙锁，但要小心不可重复读问题。
索引是锁的基石: InnoDB 的行锁是加在索引记录上的。如果你WHERE条件没有命中索引，InnoDB 可能会退化到全表扫描并加表锁或对扫描的所有行加行锁（取决于具体操作和隔离级别），那并发性就惨不忍睹了！请务必为你的查询条件加上合适的索引！🔑
尽量缩短事务的持续时间: 事务开启得越久，持有的锁就越久，其他事务等待锁的可能性就越大。写 SQL 时，尽量把操作放在一个事务里一次性完成，减少事务的开销。
- “少壮不努力，老大写事务！” 🤣
避免大事务: 一次修改太多数据的大事务会长时间锁定大量资源，严重影响并发。考虑拆分成小事务分批处理。
以固定的顺序访问资源: 这是避免死锁的经典方法！如果所有事务都以相同的顺序访问和锁定资源（比如总是先锁表A，再锁表B；或者总是先锁ID小的记录，再锁ID大的记录），死锁的概率会大大降低。想象一下，大家都按顺序排队，就不会出现“你等我，我等你”的僵局了。🚦➡️
监控你的锁: 定期查看 SHOW ENGINE INNODB STATUS 或 performance_schema，了解数据库的锁等待情况，及时发现和解决潜在的性能瓶颈和死锁问题。
审慎使用 SELECT ... FOR UPDATE 和 SELECT ... FOR SHARE: 它们会将普通的快照读变成当前读并加锁。只在确实需要在读数据后立即进行写操作，并且需要保证读到最新数据版本时使用。不必要的加锁会降低并发性。
慎用手动表锁 LOCK TABLES: 它会直接锁住整个表，比行锁粗暴得多，非必要不使用。