myisam仅支持表锁，读读不阻塞但读写互斥，且写优先导致读等待；innodb默认行锁，实际锁索引项，依赖索引与隔离级别，rr级下使用临键锁防幻读，间隙锁易引发隐性阻塞。
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 级别。
