update或delete锁整张表是因为where条件未走索引，innodb被迫全表扫描并逐行加next-key锁，锁行数接近全表且覆盖所有插入间隙，等效锁表；根本原因是优化器退化为聚簇索引顺序遍历，而非真正加表锁。
为什么 UPDATE 或 DELETE 会锁整张表？
不是 MySQL 主动“升级”为表锁，而是 InnoDB 在找不到可用索引时，无法精确定位要修改的行，只能走全表扫描 —— 每扫到一行就加一个行锁，但事务未提交前这些锁都得一直挂着。如果扫描行数太多（比如几万、几十万），InnoDB 会触发 innodb_lock_wait_timeout 超时，或更常见的是：客户端感知到“卡死”，DBA 查 SHOW ENGINE INNODB STATUS 发现大量 LOCK WAIT 状态，误以为是“升级成了表锁”。实际仍是行锁，只是数量爆炸+持有时间长，效果等同于表不可写。
怎么快速确认是不是索引缺失导致的锁扩散？
执行出问题的 UPDATE 或 DELETE 前，先用 EXPLAIN 看执行计划：
EXPLAIN UPDATE user SET status = 1 WHERE phone = '13800138000';
重点看这几项：
-
type是ALL或index→ 没走有效索引，危险 -
key显示NULL→ 完全没用索引 -
rows数值极大（远超你预期匹配的行数）→ 扫描范围失控 - 哪怕
key有值，但possible_keys列出多个，而key只选了其中一个前缀不匹配的 → 可能走了低效索引
加索引不是万能的，这几种情况要特别小心
即使加了索引，也可能因数据特征或语句写法导致锁范围扩大：
- 对
TEXT/VARCHAR字段用LIKE '%xxx'→ 索引失效，退化为全表扫描 - 在
WHERE中对索引字段用了函数，比如WHERE DATE(create_time) = '2025-01-01'→ 索引无法下推 - 联合索引顺序错：比如建了
(a, b)，但查询只用了WHERE b = ?→ 跳过最左前缀，索引无效 - 字段类型隐式转换：比如
phone是VARCHAR，但写成WHERE phone = 13800138000（无引号）→ 触发全表类型转换，索引失效
线上紧急处理和长期规避建议
已经卡住？别直接 KILL 连接，先查清事务源头：
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED DESC LIMIT 5;
拿到 TRX_MYSQL_THREAD_ID 后再决定是否 kill。长期来看，必须做到：
- 所有高频
UPDATE/DELETE的WHERE条件字段，必须有单列或符合最左前缀的联合索引 - 批量更新分页做，用主键范围切分：
WHERE id BETWEEN 10000 AND 10100，避免LIMIT+OFFSET导致越往后越慢、锁越久 - 开发阶段强制要求：任何 DML 上线前，必须贴出
EXPLAIN结果并由 DBA 确认type不是ALL - 监控慢日志中
Rows_examined异常高的语句，它们就是潜在的锁风暴源头
真正麻烦的从来不是“没索引”，而是“以为加了索引就安全了”，结果因为类型不匹配或写法不当，索引根本没被用上。
