各位看官，大家早安午安晚安呀~~~
如果您觉得这篇文章对您有帮助的话
欢迎您一键三连，小编尽全力做到更好
欢迎您分享给更多人哦

今天我们来学习：MySQL锁的分类 && MVCC和S/X锁的互补关系

1.锁分类

1.按锁粒度分类：全局锁，表级锁，行级锁
2.按照锁模式分类：.共享锁（Shared Lock，S 锁），排他锁（Exclusive Lock，X 锁）
3.特殊锁类型: 意向锁（表锁，Intention lock）， 间隙锁（Gap Lock），临键锁（Next-Key Lock）

2.按锁粒度分类

2.1. 全局锁（Global Lock）
特点：对整个数据库实例加锁，阻塞所有 DML 和 DDL 操作。
命令：FLUSH TABLES WITH READ LOCK;
优点：
实现简单，确保数据一致性（如全量备份）。

2.2. 表级锁（Table Lock）
特点：对整张表加锁，开销小、加锁快。
命令：LOCK TABLES table_name READ/WRITE;
优点：
开销小，适合批量操作（如批量插入）

2.3.行级锁
行级锁（Row Lock）
特点：对索引记录加锁，仅 InnoDB 存储引擎支持。
优点：
锁粒度最小，并发性能最高（不同事务可同时操作不同行）。

3.按照锁模式分类

1. 共享锁（Shared Lock，S 锁）
核心规则：
事务对资源加 S 锁后，允许其他事务加 S 锁（共享读），但禁止其他事务加 X 锁（禁止写）。
即：“可以同时读，不能同时写”。
适用场景：
仅读取数据，不修改时使用（如SELECT ... LOCK IN SHARE MODE;）。

2.排他锁（Exclusive Lock，X 锁）
核心规则：
事务对资源加 X 锁后，禁止其他事务加任何锁（既不能读，也不能写）。
即：“写的时候，既不能同时读，也不能同时写”。
适用场景：
修改数据时使用（如UPDATE/DELETE，数据库会自动加 X 锁；或显式加锁SELECT ... FOR UPDATE;）。

意向锁是表级锁，它的设计是为了协调行级锁和表级锁的关系，避免 “行锁与表锁” 之间的冲突检测效率低下。

4.问题：

4.1. 为什么需要意向锁？

它的核心作用：是通过表级标记 优化行级锁和表级锁之间的冲突检查，减少锁检查的开销

假设没有意向锁，当事务 A 对表中某行加 S 锁，此时事务 B 想对整个表加 X 锁（如ALTER TABLE），数据库需要：

检查表中所有行是否有 S 锁 / X 锁（逐行扫描）。
若表中数据量极大（如 1000 万行），逐行检查会导致性能灾难。

意向锁的作用：提前声明 “事务想对表中的行加 S 锁或 X 锁”，让表级锁的冲突检测只需检查意向锁，无需扫描全行。

2. 意向锁的类型

意向锁是表级锁，分为两种：

意向共享锁（IS 锁）：事务声明 “未来可能对表中某些行加 S 锁”。
意向排他锁（IX 锁）：事务声明 “未来可能对表中某些行加 X 锁”。

3. 意向锁的工作流程

事务对行加 S 锁 / X 锁前，必须先对表加对应的意向锁：

事务想对某行加 S 锁 → 先对表加 IS 锁 → 再对行加 S 锁。
事务想对某行加 X 锁 → 先对表加 IX 锁 → 再对行加 X 锁。
这样的话 =》如果加表锁的话，一看到有意向锁就阻塞等待

总之：意向锁既是一种标记（标记事务的意图，它不直接锁定任何行数据，而是在表级别记录事务的操作方向（读还是写）），也是真正的锁（有锁的阻塞和兼容规则）

它的核心作用：是通过表级标记优化行级锁和表级锁之间的冲突检查，减少锁检查的开销

4.2总结：MVCC 与锁的互补关系

为啥有mvcc还需要互斥锁和排他锁？？？

1.肯定是mvcc有局限性呀

MVCC 的优势是提升读写并发性能，但它无法解决所有场景的并发问题，主要局限包括：
无法处理 “写写冲突”：多个事务同时修改同一行数据时，MVCC 只能通过 “后提交的事务覆盖先提交的” 或 “事务回滚” 处理，无法保证修改的原子性和一致性（必须靠锁解决）；
无法满足 “强一致性读” 需求：如果业务要求 “读取的数据必须是最新的，且在读取期间不被修改”（如金融对账、库存扣减前的校验），MVCC 的 “读历史版本” 机制就不适用了；
无法处理范围操作的并发问题：如SELECT ... FOR UPDATE（锁定查询范围内的所有行），MVCC 无法保证范围操作的原子性（必须靠锁锁定范围）

2.MVCC 和 S/X 锁并非对立，而是协同工作：

MVCC 负责优化 “读写并发”：让读操作无需加锁，提升查询性能；
S/X 锁负责解决 “写写冲突” 和 “强一致性需求”：保证修改的原子性、数据的一致性，以及特殊场景下的读写安全。

例如：
普通SELECT（无锁）：通过 MVCC 读取历史版本，不阻塞写，提升并发；
SELECT ... FOR SHARE（加 S 锁）（强一致性需求）：通过 S 锁保证读取最新数据，且期间不被修改；
UPDATE/DELETE：通过 X 锁（写写冲突）保证同一时间只有一个事务能修改，避免脏写。
因此，即使有 MVCC，共享锁和排他锁仍是必不可少的 —— 它们解决了 MVCC 无法覆盖的并发场景，共同保证数据库的 ACID 特性。