SQL行锁与表锁由存储引擎、隔离级别、索引使用及是否精准定位记录共同决定；InnoDB默认行锁但易升级为大范围锁，MyISAM仅支持表锁；核心是能否用索引高效定位数据。
SQL 中的行锁和表锁不是由 SQL 语句类型直接“决定”的，而是由存储引擎、隔离级别、索引使用情况以及语句是否能精确命中记录共同决定的。InnoDB 默认加行锁，但很容易“升级”为表锁或锁住更大范围；MyISAM 只支持表锁。关键不在“写什么语句”，而在“能不能用索引高效定位数据”。
行锁触发的核心条件
InnoDB 行锁生效的前提是：语句走索引（主键或唯一/普通索引），且能明确锁定具体行。否则会退化为间隙锁、临键锁，甚至全表扫描导致锁表。
- UPDATE 或 DELETE 带 WHERE 条件，且 WHERE 中的字段有有效索引 → 通常加行级记录锁（Record Lock）
- WHERE 条件命中唯一值（如主键 = 100）→ 锁单行（含可能的间隙锁，取决于隔离级别）
- WHERE 条件走普通索引，但结果多行 → 对每行加记录锁，同时在索引间隙加间隙锁（Gap Lock），防止幻读
- SELECT ... FOR UPDATE / LOCK IN SHARE MODE 在可重复读（RR）下，也会按上述规则加行锁或临键锁（Next-Key Lock）
表锁（或锁升级）常见场景
InnoDB 本身不直接支持传统意义的表锁，但在以下情况会实际效果等同于锁表：
外贸英文智能门锁独立站源码2.0.7
下载
这款 Zancms 外贸英文电子产品手表网站源码是专为外贸业务打造。它由 zancms 外贸独立站系统基于智能门窗出口企业的独特需求进行研发设计，不仅适用于智能门锁类企业，对各类智能产品企业的出口业务拓展同样大有裨益。 其具备显著的语言优势，采用英文界面呈现，且内置智能 AI 翻译功能，在获得商业授权后更可开启多语言模式，充分满足不同地区用户的语言需求，并且整个网站的架构与布局完全
- WHERE 条件未使用任何索引（全表扫描）→ 每扫描一行都尝试加锁，最终几乎锁住所有行，CPU 和锁开销极大，业务上视为“锁表”
- 对无主键、无索引的表执行 DML → 必然全表扫描，锁全部聚簇索引记录
- 显式执行 LOCK TABLES（InnoDB 支持但不推荐）→ 真正的表级锁，会禁用事务自动提交，影响并发
- 大量更新引发锁升级？注意：InnoDB 不会自动将行锁升级为表锁，但高并发下锁冲突严重时，可能因等待超时或死锁检测导致批量失败，给人“锁表”错觉
隔离级别如何影响锁行为
锁的类型和范围与事务隔离级别强相关，尤其在 RR（可重复读）下：
- 读已提交（RC）：只加记录锁，不加间隙锁 → 幻读可能发生，但锁粒度更小，冲突少
- 可重复读（RR）：默认加临键锁（记录锁 + 间隙锁）→ 防止幻读，但会锁住 WHERE 条件涉及的整个索引区间（例如 WHERE age BETWEEN 25 AND 30，可能锁住 25~30 之间所有间隙）
- 若 WHERE 条件无法使用索引，RR 下仍会扫描全表并加临键锁 → 实际锁住整张表的索引范围
如何验证当前语句加了什么锁
靠经验判断不如直接查锁状态。常用方法：
- 执行 SELECT * FROM performance_schema.data_locks;（MySQL 8.0+）→ 查看事务持有的锁类型、锁对象（TABLE / RECORD）、索引名、锁模式（LOCK_S, LOCK_X, LOCK_GAP 等）
- 配合 SELECT * FROM performance_schema.data_lock_waits; 查阻塞关系
- 老版本可用 SHOW ENGINE INNODB STATUS\G，关注 TRANSACTIONS 部分的 lock wait 和 lock struct
- EXPLAIN 执行计划确认是否走了索引，是预判锁粒度的第一步
