MySQL锁机制本质是解决多事务并发访问数据冲突、保障一致性和隔离性的分层多粒度体系；按粒度分全局锁、表级锁、行级锁、页锁；按操作分共享锁（S）和排他锁（X）；按策略分悲观锁与乐观锁；另有意向锁、MDL、自增锁等辅助锁。
MySQL 的锁机制，本质是为了解决多个事务同时访问同一数据时可能引发的冲突问题，保障数据的一致性和隔离性。它不是单一功能，而是一套分层、多粒度、按需协作的控制体系。
按粒度划分：从大到小，影响并发的关键
锁的粒度直接决定并发能力高低：
-
全局锁：锁定整个数据库实例，让所有表进入只读状态。典型命令是
FLUSH TABLES WITH READ LOCK，常用于全库逻辑备份。缺点是业务写操作完全阻塞。 - 表级锁：一次锁住整张表。MyISAM 默认使用；InnoDB 在某些场景（如无索引条件更新）也会退化为表锁。开销小、不会死锁，但并发度最低。
- 行级锁：InnoDB 默认且最常用的锁，只锁定满足条件的单行或若干行（实际锁在索引记录上）。并发度最高，但加锁慢、开销大，且可能死锁。
- 页锁：介于表锁与行锁之间，锁定磁盘中相邻的一组记录（通常 8KB 一页），BDB 引擎曾使用，现在较少见。
按操作类型划分：读与写的权限边界
这是最基础的行为控制逻辑：
-
共享锁（S 锁 / 读锁）：用
SELECT ... LOCK IN SHARE MODE显式加锁。允许多个事务同时持有 S 锁，可并发读，但阻止任何 X 锁（即禁止写）。 -
排他锁（X 锁 / 写锁）：用
SELECT ... FOR UPDATE或隐式出现在UPDATE/DELETE/INSERT中。一个事务持有 X 锁时，其他事务无法再加 S 锁或 X 锁，读写全被阻塞。
按实现策略划分：对并发风险的不同预判
这反映的是设计哲学差异：
- 悲观锁：假设冲突大概率发生，提前加锁保护。MySQL 中的 S 锁、X 锁就是典型实现，适合写多、一致性要求严的场景（如订单扣减）。
-
乐观锁：不真正加锁，而是靠版本号（
version字段）或时间戳比对，在提交时检查是否被修改。适合读多写少、冲突概率低的场景（如文章浏览计数）。
特殊辅助锁：支撑多粒度协同的“信号灯”
这些锁不直接锁数据，但对锁效率和安全性至关重要：
- 意向锁（IS/IX）：事务要给某几行加 S/X 锁前，必须先给整张表加 IS/IX 锁。它本身不阻塞读写，但能快速告诉别人“这张表有行正被锁”，避免全表扫描判断。
-
元数据锁（MDL）：执行
SELECT或 DDL（如ALTER TABLE）时自动加，防止结构变更与查询/修改同时发生，保证语句解析一致性。 -
自增锁（AUTO-INC Lock）：确保
AUTO_INCREMENT列生成唯一值，是轻量级表级锁，仅在插入时短暂持有。
