MySQL InnoDB的UPDATE若WHERE字段无索引或索引未被使用，会全表扫描并加记录锁与间隙锁，等效锁表；需用EXPLAIN确认索引使用、避免隐式转换、控制事务时长、优先JOIN而非子查询。
WHERE条件字段没索引，UPDATE直接扫全表加锁
MySQL InnoDB 的 UPDATE 默认走行锁，但前提是 WHERE 条件能命中索引。一旦字段没索引、或索引失效（比如对字段做函数操作：WHERE DATE(created_at) = '2026-05-01'），优化器就会退化为全表扫描——所有被扫描的行都会被加上记录锁，间隙锁也会随之激活，最终效果等同于锁整张表。
常见现象是：执行一条看似简单的 UPDATE users SET status = 'done' WHERE mark_id = 123，却让后续所有 INSERT、SELECT、甚至其他 UPDATE 都卡在 Waiting for table metadata lock 或 Locked 状态。
- 用
EXPLAIN看执行计划：type是ALL、rows接近表总行数，基本可断定没走索引 - 检查
SHOW INDEX FROM table_name，确认 WHERE 字段是否有可用索引（注意前缀索引、组合索引顺序） - 避免隐式类型转换：比如
mark_id是VARCHAR，但传入数字123，会导致索引失效
索引存在但没被选中，UPDATE仍会锁表
有索引不等于会被用。InnoDB 是否加行锁，取决于优化器是否真用了那个索引。即使 mark_id 上建了索引，如果该字段重复值过多（比如 status 字段只有 'pending'/'done' 两种值），优化器可能认为走索引比全表扫描更慢，直接放弃索引。
这时 UPDATE 依然会扫描大量无关行，锁范围爆炸式扩大。
- 用
EXPLAIN FORMAT=JSON查看used_key和key_length，确认实际使用的索引及长度 - 强制走索引：
UPDATE users FORCE INDEX (idx_mark_id) SET status = 'done' WHERE mark_id = 123 - 对高重复率字段，考虑配合主键分段：先
SELECT id FROM users WHERE mark_id = 123 ORDER BY id LIMIT 1000，再用WHERE id IN (...)更新（注意IN列表长度限制）
事务未提交导致行锁升级为临键锁甚至表锁
锁表时间 ≠ SQL 执行时间，而是从 BEGIN 到 COMMIT 的整个事务窗口。哪怕 UPDATE 本身毫秒级完成，只要事务没结束，锁就一直挂着；期间若发生范围扫描、间隙匹配，InnoDB 会自动补上间隙锁，把相邻空隙也锁死——这就是为什么有时只改一行，却阻塞了其他插入。
- ORM 框架（如 Spring 的
@Transactional）容易在事务里混入 HTTP 调用、日志写入等耗时操作，把锁拖长 - 连接池复用时，上一个请求忘了
commit，下一个请求复用同一连接，锁直接继承 - 用
SELECT * FROM information_schema.INNODB_TRX查长事务，重点关注TRX_STARTED和TRX_STATE
UPDATE JOIN 和子查询的锁行为差异极大
UPDATE t1 JOIN t2 ON t1.id = t2.t1_id 和 UPDATE t1 WHERE id IN (SELECT id FROM t2) 看似等价，锁机制却天差地别。后者在 MySQL 5.7 及以前版本中，子查询结果集所有行都会被加锁（哪怕最终没更新），且极易触发临时表和全表扫描；前者则只锁真正参与 JOIN 和更新的行。
- 优先用
JOIN写法，明确控制锁范围 - 必须用子查询时，确保子查询能命中索引，并加
FORCE INDEX提示 - 避免
UPDATE ... WHERE id IN (SELECT ...)套在大表上，改用分批主键列表 +WHERE id IN (1,2,3...)
真实锁表往往不是单点问题，而是索引缺失 + 事务拖沓 + 查询写法不当三者叠加。最危险的是“看起来有索引，但根本没被用”，这种场景下 EXPLAIN 必须每批都跑，不能凭经验跳过。
