排他锁（X 锁）与共享锁（S 锁）最本质的区别在于是否允许其他事务同时加任何锁：X 锁阻塞所有并发锁（S/X），S 锁允许多个 S 锁共存但阻塞 X 锁。
排他锁（X 锁）和共享锁（S 锁）最本质的 区别 是什么
区别不在“能不能读”，而在“能不能让别人同时写或读写混合”——SELECT …… FOR UPDATE 加的是排他锁，它会彻底拦住其他事务对同一行加任何锁（包括 SELECT …… LOCK IN SHARE MODE）；而 SELECT …… LOCK IN SHARE MODE 加的是共享锁，只拦写、不拦读，多个事务可以同时持有它。
- 共享锁（S 锁）：事务 A 加了 S 锁，事务 B 还能立刻加 S 锁，但加
FOR UPDATE会被阻塞 - 排他锁（X 锁）：事务 A 加了 X 锁，事务 B 再想加 S 锁或 X 锁，全都会被阻塞，直到 A 提交或回滚
- 普通
SELECT不加任何锁（快照读），除非显式加锁或开启串行化隔离级别 -
INSERT/UPDATE/DELETE默认隐式加 X 锁，无需手动写FOR UPDATE
什么时候该用 FOR UPDATE，什么时候用 LOCK IN SHARE MODE
核心看业务是否要“读完就改”——如果只是校验数据后准备更新，必须用 FOR UPDATE；如果只是读取做展示或只读校验（比如查余额够不够、但不扣款），用 LOCK IN SHARE MODE 更轻量。
- 典型场景：
SELECT balance FROM account WHERE id = 123 FOR UPDATE;→ 防止并发扣款时超扣 - 反例：
SELECT name, status FROM user WHERE id = 456 LOCK IN SHARE MODE;→ 没后续更新，纯属多此一举，去掉锁更高效 - 注意：如果查询条件没走索引（例如
WHERE name = 'xxx'且name无索引），FOR UPDATE会升级为表锁，严重拖慢其他操作
为什么 有时加了锁还出现脏读 / 幻读？不是说锁能解决一切吗
锁只管“当前读”，不管“快照读”。InnoDB 默认的 REPEATABLE READ 隔离级别下，普通 SELECT 走的是 MVCC 快照，根本看不到你刚加的锁保护的数据版本；只有显式加锁的语句（FOR UPDATE / LOCK IN SHARE MODE）才触发当前读，看到最新已提交数据。
- 现象举例：事务 A 执行
SELECT …… FOR UPDATE锁住某行并修改，但还没提交；事务 B 执行普通SELECT，仍能看到旧值（快照）；只有 B 也执行SELECT …… FOR UPDATE才会被阻塞或看到新值 - 幻读问题：即使对现有行加了 X 锁，也无法阻止其他事务插入满足相同
WHERE条件的新行（除非配合间隙锁或使用SELECT …… FOR UPDATE+ 唯一索引 / 主键覆盖） - 真正起作用的，是锁 + 隔离级别 + 索引三者协同；单靠一个
FOR UPDATE无法包打 天下
意向锁（IS/IX）不是用户直接操作的，但它怎么影响你的加锁行为
意向锁是 InnoDB 自动加的表级“占位符”，你没感知，但它决定了你能否顺利拿到行锁——比如事务 A 正在对某行加 X 锁，它会先在表上加 IX 锁；此时事务 B 想对该表加表级 LOCK TABLES …… WRITE，就会被立刻拒绝，因为 IX 和表写锁冲突。
- 你不需要写
INTENTION SHARE这种语句，MySQL 会在你执行SELECT …… LOCK IN SHARE MODE前自动加IS锁 - 如果你看到
SHOW ENGINE INNODB STATUS里有大量waiting for table metadata lock，往往是因为某个长事务持有了 IX 锁（比如一个未提交的UPDATE），而另一个 DDL（如ALTER TABLE）在等表级独占锁 - 排查时别只盯着行锁，
INFORMATION_SCHEMA.INNODB_TRX和INNODB_LOCK_WAITS才是定位锁等待链的关键
锁不是越重越好，也不是加了就万事大吉。真正难的，是在读写混合、索引缺失、事务边界模糊的场景下，判断哪一行实际被锁、谁在等谁、为什么没按预期阻塞——这些细节，藏在执行计划、锁类型输出和事务状态里，而不是语法本身。
