MyISAM只用表锁，读写互斥但读读不阻塞
MyISAM 引擎没有事务、没有行锁，所有 DML 操作都靠表级锁兜底。执行
SELECT前自动加读锁，
INSERT/UPDATE/DELETE前自动加写锁——你几乎不用手动
LOCK TABLES，除非做特殊调度。
但要注意：读锁允许并发读，但会阻塞写；写锁则独占整张表，连其他会话的
SELECT都会被挂起。更关键的是，MyISAM 的锁调度策略是「写优先」，一旦有写请求排队，后续的读请求可能无限等待。 现象：
INSERT执行中，另一个会话执行
SELECT * FROM t会卡住，直到写完成 坑点：
LOCK TABLES t WRITE后，当前会话必须先
UNLOCK TABLES才能访问其他表，否则报错
Table 'x' was not locked with LOCK TABLES适用场景：报表类只读库、日志归档表等低并发、高吞吐读取场景
InnoDB 默认行锁，但实际加锁依赖索引和隔离级别
InnoDB 的行锁不是直接锁“数据行”，而是锁“索引项”——哪怕你
SELECT * FROM t WHERE id = 100，真正被加锁的是
id索引上值为
100的那个 B+ 树节点。没索引？那就会退化成锁全表（通过意向锁 + 表锁配合实现）。
而且锁行为随事务隔离级别变化：
READ COMMITTED下只加记录锁（Record Lock）；
REPEATABLE READ下默认加临键锁（Next-Key Lock），即记录锁 + 间隙锁（Gap Lock），用来防幻读。 常见误判：以为
SELECT ... WHERE name = 'Alice'只锁匹配行——如果
name没索引，InnoDB 会扫描全表并给每条记录加 X 锁 验证方法：执行语句后查
SELECT * FROM performance_schema.data_locks（MySQL 8.0+）或
SHOW ENGINE INNODB STATUS性能影响：间隙锁在范围查询（如
WHERE age BETWEEN 20 AND 30）时会锁住整个区间，可能意外阻塞看似无关的
INSERT
意向锁是隐式协调者，你不用加但必须懂它存在的原因
当你对某行加 X 锁时，InnoDB 会自动在表级别加上
IX（意向排他锁）；加 S 锁则加
IS（意向共享锁）。它本身不阻塞任何操作，但它是表锁与行锁之间的“签证官”：如果有人已持表级
X锁，你就无法再对任意行加
X锁，因为
IX和表级
X冲突。
这个机制避免了每次加行锁都要遍历全表检查是否已被表锁占用——效率提升的关键设计。
典型冲突链：LOCK TABLES t WRITE→ 表级 X 锁 → 后续任何
SELECT ... FOR UPDATE都会等待，即使只查一行 调试线索：若发现某行更新莫名卡住，先看是否有会话在用
FLUSH TABLES WITH READ LOCK或显式
LOCK TABLES注意：
IX/IS是自动加的，你不能也不该手动操作它们
全局锁仅用于备份，生产环境慎用 FTWRL
FLUSH TABLES WITH READ LOCK（FTWRL）会阻塞所有 DML 和 DDL，连
CREATE TEMPORARY TABLE都不行。它唯一合理用途是给 MyISAM 或无事务引擎做一致性逻辑备份。
对 InnoDB，应优先用
mysqldump --single-transaction：它启动一个 RR 隔离级别的快照事务，全程不阻塞写入。只有在备份期间有长事务运行，才可能因 undo log 膨胀引发问题。 危险信号：执行
FLUSH TABLES WITH READ LOCK后，
SHOW PROCESSLIST里大量线程状态变成
Waiting for table flush替代方案：Percona XtraBackup 或 MySQL 8.0+ 的
BACKUP DATABASE命令，均支持热备 致命限制：FTWRL 无法跨实例同步，主从切换时若从库正在 FTWRL，会导致复制中断
实际调优中最容易被忽略的，是间隙锁在
REPEATABLE READ下的“隐形覆盖”——它不报错、不告警，却让看似独立的插入操作互相等待。排查时别只盯着 SQL 是否命中索引，还要看 WHERE 条件是否构成范围、索引是否唯一、事务是否真正在用 RR 级别。
