UPDATE不走索引必然导致全表扫描并逐行加X锁，引发锁扩大和死锁高风险；根本原因是InnoDB无法精准定位行，只能遍历聚簇索引并对每条记录加锁，效果等同于锁表。
UPDATE 不走索引不是“偶尔失灵”，而是必然引发锁扩大和死锁高风险——它让 InnoDB 无法精准定位行，只能全表扫描并逐行加 X 锁，锁住成千上万本不该碰的记录。
为什么 EXPLAIN 显示走了索引，但 UPDATE 还是锁全表？
常见错觉：看到 EXPLAIN 的 type 是 ref 或 range，就以为锁安全。其实 UPDATE 加锁行为不完全等同于 SELECT 的执行计划。
- 隐式类型转换会让索引失效：比如
user_id是INT，但写成WHERE user_id = '123'，MySQL 会转成字符串比对，索引直接丢弃 - 函数包裹字段：如
WHERE UPPER(name) = 'ALICE'，哪怕name有索引，也无法使用 - 统计信息过期导致优化器误判：
ANALYZE TABLE没跑过，优化器可能认为全表扫描比走索引更快，尤其在小表或数据分布突变后 - 联合索引未满足最左前缀：
INDEX (status, created_at)，但查询只用WHERE created_at > '2026-01-01'，该索引基本无效
如何验证 UPDATE 实际是否走索引并控制锁范围？
不能只信 EXPLAIN SELECT，得看真实 UPDATE 的加锁行为。最可靠方式是结合执行计划 + 锁视图 + 死锁日志交叉验证。
- 先跑
EXPLAIN FORMAT=TRADITIONAL UPDATE ...（MySQL 8.0+ 支持），重点看key是否命中预期索引、rows是否接近实际匹配数 - 若
Extra出现Using filesort或Using where; Using index condition但key为空，说明索引没生效 - 开启
innodb_print_all_deadlocks = ON，从 error log 中抓死锁现场，看日志里锁住的记录 ID 是否离散（如 id=5, 102, 999…）还是大片连续（如 id=1–10000），后者大概率是全表扫描 - 事务中执行 UPDATE 后不提交，立刻查
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS，观察LOCK_TRX_ID和LOCK_DATA，若LOCK_DATA显示大量非预期主键值，说明锁范围失控
统计信息不准或索引失效时的应急与长期对策
统计信息不是“设一次就永远有效”的配置，它随数据增删而漂移；索引也不是建完就自动“永不失效”的保障。
- 紧急修复：对问题表手动更新统计信息 ——
ANALYZE TABLE t_name;，尤其在大批量 INSERT/DELETE 后必须做 - 避免隐式转换：应用层确保传参类型与字段一致，
INT字段别传字符串，DATETIME别传时间戳数字 - 检查索引有效性：用
SHOW INDEX FROM t_name;确认索引状态，再用SELECT COUNT(*) FROM t_name WHERE indexed_col IS NULL;看是否存在大量空值干扰选择性 - 监控高频 UPDATE 语句：在 slow log 中打开
log_queries_not_using_indexes = ON，但注意它只对 SELECT 生效；真正要捕获 UPDATE 索引问题，得靠performance_schema.events_statements_history_long查NO_INDEX_USED标记
最容易被忽略的一点：即使索引存在、类型匹配、统计信息最新，如果 WHERE 条件中混用了 OR（尤其是跨字段 OR）、NOT IN 子查询或 JSON_CONTAINS 等非常规操作，优化器仍可能放弃索引。这种场景下，拆成多个单条件 UPDATE 或改用临时表预过滤，往往比硬调索引更可控。
