行锁只锁被操作的那几行，表锁会锁整张表
MySQL 的锁粒度直接决定并发能力。InnoDB 默认用
ROW_LOCK（行级锁），比如执行
UPDATE users SET name='a' WHERE id=10，只会给
id=10这一行加锁；而 MyISAM 只支持
TABLE_LOCK（表级锁），哪怕你只更新一条记录，整个
users表都不可写。
行锁靠索引实现——没走索引的
WHERE条件（如
WHERE status='draft'且
status无索引），InnoDB 可能退化为锁全表（准确说是锁所有扫描到的行，但效果接近表锁）。 行锁开销大、加锁慢，但并发高、冲突少 表锁开销小、加锁快，但一写就堵住所有其他写操作 显式加表锁用
LOCK TABLES users WRITE，必须配对
UNLOCK TABLES
间隙锁（Gap Lock）是行锁的延伸，只存在于可重复读（RR）隔离级别
InnoDB 的行锁不是孤立的“某一行”，而是包含前后间隙。比如
SELECT * FROM orders WHERE amount > 100 FOR UPDATE在 RR 级别下，不仅锁住所有
amount > 100的现有行，还会锁住这些行之间的“间隙”，防止其他事务插入新记录破坏当前查询结果的一致性。
这个机制能避免幻读，但也容易引发死锁或锁等待——特别是范围条件 + 无唯一索引时。
读已提交（RC）级别下，Gap Lock被禁用，只锁实际命中的行
INSERT操作在 RR 下可能触发
Insert Intention Lock，和
Gap Lock冲突 唯一索引等值查询（如
WHERE id=5）不会加
Gap Lock，只加
Record Lock
如何查当前有哪些锁在生效
不能只看 SQL 写得“像不像只影响一行”——锁的实际范围得靠运行时信息验证。最直接的方式是查
information_schema.INNODB_TRX和
INNODB_LOCKS（MySQL 5.7）或
performance_schema.data_locks（8.0+）。
常用组合：
SELECT trx_id, trx_state, trx_started, trx_query FROM information_schema.INNODB_TRX;
再关联
INNODB_LOCK_WAITS看谁在等谁，或者用
SHOW ENGINE INNODB STATUS\G查最近的死锁详情。
trx_state = 'LOCK WAIT'表示该事务正在等锁 注意
trx_query显示的是被阻塞前最后执行的语句，不一定是加锁源 8.0 中
data_locks表里
LOCK_DATA字段会显示具体锁住的主键值或间隙范围
锁升级不存在，但锁数量爆炸会导致性能陡降
MySQL（尤其是 InnoDB）没有“行锁自动升级为表锁”的机制。但如果你在事务中批量更新 10 万行，InnoDB 就真会持有着 10 万个行锁——内存占用飙升、锁管理开销变大、甚至触发
innodb_lock_wait_timeout超时。
这时候看似是“锁太多”，本质是事务粒度太大。优化方向不是换锁类型，而是拆事务、加覆盖索引减少扫描行数、或改用
UPDATE ... LIMIT N分批处理。 大批量更新尽量避开业务高峰 确认是否真的需要事务包裹全部操作——有些日志类更新可设为
AUTOCOMMIT=1使用
EXPLAIN确保
WHERE条件走了索引，否则锁的行数远超预期
锁的实际行为高度依赖隔离级别、索引结构和语句执行计划，光记“行锁好、表锁差”没用。真正踩坑的地方，往往出在“我以为只锁一行，其实锁了一片”。
