MySQL锁不是一种锁，而是一套分层、多维、按需启用的并发控制机制；实际开发中你遇到的“卡住”“死锁”“查不到最新数据”，几乎都和它有关。
按粒度分：表锁、行锁、间隙锁，别乱用
粒度决定并发能力——越细越快，但也越难管。
表锁（
LOCK TABLES t1 READ/WRITE）：整张表被锁死，其他事务连
SELECT都可能被阻塞（尤其
WRITE锁）。MyISAM 默认用它；InnoDB 仅在没走索引、全表扫描或显式调用时才退化为表锁。
行锁（InnoDB 默认）：只锁命中索引的那几行。但注意：没索引 = 没行锁，InnoDB 会直接升级为表锁。
Gap Lock和
Next-Key Lock：只在
REPEATABLE-READ隔离级别生效，用于防止幻读。比如
WHERE id BETWEEN 10 AND 20，会锁住 (10,20) 这个间隙，甚至 (10,20]（含20行）。
READ-COMMITTED下这些锁不生效，行锁退化为纯
Record Lock。
按行为分：S锁、X锁、IS/IX锁，必须懂意向锁的作用
你写
SELECT ... FOR UPDATE加的是 X 锁，但 InnoDB 实际上先申请
IX表级意向锁——这是为了快速判断“这张表有没有人正在改行”，避免每次加行锁都扫全表。
S锁（共享锁）：
SELECT ... LOCK IN SHARE MODE加的，允许多个事务同时读，但谁都无法加 X 锁。
X锁（排他锁）：
UPDATE、
DELETE、
SELECT ... FOR UPDATE默认加的，互斥一切其他锁。
IS/IX锁是“预告”：事务还没锁行，但声明“我马上要锁几行读/写”，让表级操作（如
DROP TABLE）能立刻感知冲突并拒绝，而不是等到最后才发现。
按实现逻辑分：悲观锁 vs 乐观锁，别拿 version 字段硬套 InnoDB
InnoDB 的行锁是典型的悲观锁实现；而所谓“乐观锁”，MySQL 本身不提供原生命令，
version字段方案是你自己在应用层写的逻辑，数据库只负责执行
UPDATE ... WHERE version = ?并返回影响行数。 真用悲观锁？确保 SQL 走索引、事务尽量短、避免
SELECT ... FOR UPDATE后长时间不提交。 想用乐观锁？别依赖 MySQL 自动处理，
UPDATE必须带
WHERE version = xxx，且检查
affected_rows == 1，否则就是更新丢失。 MVCC 不是乐观锁，它是快照读机制：普通
SELECT不加锁，靠隐藏字段
DB_TRX_ID和
DB_ROLL_PTR回溯版本——这正是为什么你
UPDATE未提交时，别人
SELECT还能看见旧值。
实战中最容易踩的三个坑
很多“锁表现异常”，其实不是锁错了，而是没看清隔离级别、索引状态或事务边界。
在READ-COMMITTED下还指望
Gap Lock防幻读？不行。它只在
REPEATABLE-READ生效。 执行
UPDATE t SET x=1 WHERE y=999卡住？先
EXPLAIN看是否走了索引；没走，就等于锁了全表。 用
FOR UPDATE却发现没锁住？确认语句是否在事务内（
BEGIN/
START TRANSACTION），且事务没提前
COMMIT或
ROLLBACK。
锁不是配置项，是执行路径的副产品；真正要盯的，永远是那条 SQL 走不走索引、跑在什么隔离级别、包没包在事务里。
