锁机制用于管理对共享资源的并发访问，用来实现事务的隔离级别

1.2.1 锁的粒度
MySQL InnoDB 支持多粒度锁，即可以对不同层级的资源加锁，从大到小分为：

表级锁：对整个表加锁（如意向锁、AUTO-INC 锁）；
页级锁：对 B+ 树的叶子节点页加锁（较少直接使用，由引擎自动管理）；
行级锁：对表中某一行记录加锁（如共享锁、排他锁）。
粒度越小，并发度越高，但锁管理开销越大；粒度越大，并发度越低，开销越小。

1.2.2 锁类型
根据作用和范围，MySQL 锁可分为以下几类：

1. 共享锁（S 锁，行级）
定义：事务对记录执行读操作时加的锁，允许其他事务加 S 锁，但阻塞 X 锁。

触发时机：

SERIALIZABLE 隔离级别下，普通 SELECT 自动加 S 锁；
其他级别需手动加锁：SELECT … LOCK IN SHARE MODE;
释放时机：事务提交或回滚后释放。

— 事务A加S锁
BEGIN;
SELECT score FROM score_tbl WHERE student_id=1 AND course_id=1 LOCK IN SHARE MODE;
— 此时事务A持有该记录的S锁

— 事务B尝试加X锁（更新操作）会被阻塞
BEGIN;
UPDATE score_tbl SET score=95 WHERE student_id=1 AND course_id=1; — 阻塞，直到事务A提交

不同隔离级别下的读操作锁机制
SERIALIZABLE
读操作锁行为：所有读操作（SELECT）会默认自动加 S 锁（无需手动指定）。

设计目标：提供最高隔离性，避免脏读、不可重复读、幻读，但牺牲并发性能（本质是 “串行执行事务”）。

底层逻辑：通过 S 锁强制阻塞修改操作 —— 只要事务 A 对某行加了 S 锁，事务 B 想修改该行（加 X 锁）就必须等待事务 A 提交 / 回滚，直到 S 锁释放。

事务 A：
BEGIN;
— 自动加S锁（SERIALIZABLE级别默认）
SELECT * FROM users WHERE id = 1;

• 事务 B：BEGIN;
  — 尝试加X锁修改，会被事务A的S锁阻塞（需等待）
  UPDATE users SET name = ‘Bob’ WHERE id = 1;
• 结果：事务 B 的 UPDATE 会被阻塞，直到事务 A 执行COMMIT或ROLLBACK释放 S 锁后，事务 B 才能继续