不是真的加了“表锁”，但效果等同于锁表，因为InnoDB对所有被扫描的主键记录都加next-key锁（记录锁+间隙锁），而无索引时Server层需全表扫描并逐行交由引擎层加锁。
不是真的加了“表锁”，但效果上等同于锁表——因为 InnoDB 对所有被扫描的主键记录都加了 next-key lock，而没索引时扫描范围就是全表。
非索引列 UPDATE 为什么实际锁住整张表
InnoDB 的行锁本质是加在索引上的，不是加在数据行本身。当 WHERE 条件字段没有索引，Server 层无法跳过无关行，只能把整张表的主键逐条交给引擎层判断；引擎层对每一条都加 X 锁，在可重复读（RR）隔离级别下还会自动带上 gap lock，合起来就是 next-key lock。
常见错误现象包括：
- 其他事务执行
SELECT ... FOR UPDATE或UPDATE时卡住不动 -
SHOW ENGINE INNODB STATUS中看到大量LOCK WAIT，但TABLE LOCK提示其实是误报（InnoDB 不会真加表锁） -
slow_log里Rows_examined等于全表行数，Lock_time显著偏高
怎么确认是不是非索引导致的锁扩大
别猜，直接看执行计划和运行时行为：
- 用
EXPLAIN FORMAT=TRADITIONAL查看语句是否走索引：type字段是ALL就危险，key字段为NULL表示没用上索引 - 在测试库开事务执行该
UPDATE，不提交，另起连接查SELECT * FROM information_schema.INNODB_TRX，观察trx_rows_locked是否接近表总行数 - 检查字段是否存在隐式转换：比如
WHERE user_id = '123'（user_id是INT），或WHERE name = BINARY 'abc'与utf8mb4列比较——这些都会让索引失效，但EXPLAIN不报错
RR 隔离级别下 gap lock 如何放大影响
哪怕你只更新一行，只要条件涉及范围（如 >=、LIKE 'abc%'），InnoDB 就可能锁住“值本身 + 后面的间隙”。例如：
UPDATE orders SET paid = 1 WHERE created_at > '2026-04-01';
若 created_at 有索引但不唯一，InnoDB 会锁定所有满足条件的记录，以及这些记录之间的间隙——实际锁住的可能是几十甚至上百行，远超你的预期。
更隐蔽的是：两个事务如果锁了重叠的间隙，再互相往对方间隙插数据，就会触发死锁。比如库存查不到记录时用 SELECT ... FOR UPDATE，直接锁整个间隙，高并发插入必炸。
sql_safe_updates=1 能不能防住这个问题
不能。它只防“没 WHERE”或“没 LIMIT”的粗放操作，防不住非索引 WHERE。真正有效的做法只有两个：
- 给
WHERE条件字段补上索引（注意区分唯一索引和普通索引对 gap lock 范围的影响） - 改写 SQL，避免函数、类型混用、
OR条件等让索引失效的写法
最常被忽略的一点是：即使加了索引，如果字段上有隐式转换或字符集不匹配，InnoDB 依然会放弃使用——这种问题不会报错，也不会在 EXPLAIN 中显式提示，只能靠 INNODB_TRX 和 INNODB_LOCKS 结合排查。
