非索引字段导致update阻塞全表读写，本质是innodb对扫描的每行主键加next-key锁；因server层无索引可依，需全表扫描并逐行加锁，效果等同锁表。
UPDATE WHERE 非索引字段为什么会阻塞全表读写
不是真的加了“表锁”，而是 InnoDB 对所有被扫描的主键记录都加了 next-key 锁（记录锁 + 间隙锁），效果等同于锁表。关键在于：InnoDB 加锁动作发生在引擎层，但扫描范围由 Server 层的 WHERE 条件决定；如果条件字段没索引，Server 层只能把整张表的行逐个扔给引擎层判断，引擎层就不得不对每行加锁。
常见错误现象包括：
• 其他事务执行 SELECT ... FOR UPDATE 或 UPDATE 时卡住不动
• SHOW ENGINE INNODB STATUS 中看到大量 LOCK WAIT 和 TABLE LOCK 提示（注意：这是误报，实际仍是行锁组合）
• 慢查询日志里 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不报错
sql_safe_updates=1 能不能防住这个问题
能，但只防“没 WHERE”或“没 LIMIT”的粗放操作，防不住非索引 WHERE。
sql_safe_updates=1 的作用是强制要求 UPDATE/DELETE 必须满足以下至少一项：
• 带 WHERE 子句且至少一个条件使用索引列
• 带 LIMIT
但它不会校验索引是否真的被优化器选用。比如你写了 WHERE created_at > '2024-01-01' 且该列有索引，但因统计信息过期或数据倾斜，优化器仍可能选 type=ALL ——这时 sql_safe_updates 不拦截，锁照样扩到全表。
真正有效的预防手段只有三个
靠人盯 EXPLAIN 不现实，得靠机制：
- 上线前 SQL 审核必须包含
EXPLAIN结果比对，重点看type、key、rows三项；大表（>10 万行）的非主键WHERE字段必须有索引 - 在开发/测试环境开启
performance_schema，用events_statements_history_long抓取慢更新，过滤ROWS_EXAMINED > 1000 AND QUERY_SAMPLE_TEXT LIKE 'UPDATE%' - 对高频更新字段，宁可冗余建联合索引。例如常按
status和created_at批量更新，就建INDEX idx_status_created (status, created_at)，而非单列索引
最易被忽略的一点：即使加了索引，如果更新语句里混用了函数（如 WHERE DATE(created_at) = '2024-01-01'）或 OR 多条件且部分无索引，同样会退化为全表扫描加锁。索引不是贴个标签就完事，得让它真被用上。
