UPDATE或DELETE会锁整张表是因为当WHERE条件未使用索引时，InnoDB退化为全表扫描，加行锁+间隙锁覆盖全表，等价于锁表；SELECT ... FOR UPDATE同理依赖索引，否则也锁全表。
为什么 UPDATE 或 DELETE 会锁整张表
MySQL 的行锁（InnoDB）不是永远只锁行——当优化器发现走不上索引，或者索引失效时，会退化为全表扫描，进而升级为表级意向锁 + 行锁无法生效，最终效果等价于锁表。
典型触发场景：对非索引字段做 WHERE 条件更新，比如 UPDATE users SET status=1 WHERE name='alice'，而 name 列没建索引。
- InnoDB 在加锁前先执行执行计划，
EXPLAIN显示type=ALL就是危险信号 - 即使表里只有 1 行匹配，只要没索引，也会遍历所有聚簇索引页，每页加记录锁 + 间隙锁，锁范围实际覆盖全表
- 并发事务一碰就冲突，
SHOW ENGINE INNODB STATUS里能看到大量LOCK WAIT和TABLE LOCK提示
SELECT ... FOR UPDATE 锁不住行？检查是不是用了非索引字段
很多人以为 SELECT ... FOR UPDATE 总是行锁，其实它和 UPDATE 一样依赖索引路径。没有可用索引时，它会锁住所有扫描过的记录——也就是全表。
例如：SELECT * FROM orders WHERE created_at > '2024-01-01' FOR UPDATE，若 created_at 无索引，就会锁所有主键记录。
- 唯一能避免的办法：确保
WHERE中每个字段都在联合索引里，且满足最左前缀原则 - 注意隐式类型转换：比如
WHERE user_id = '123'（user_id是INT），会导致索引失效，锁升级 - 字符集不一致也会让索引失效，比如
utf8mb4列和utf8字符串比较
如何快速定位锁升级的 SQL 和缺失索引
别靠猜。直接查慢日志 + 锁信息组合分析，重点看是否出现“全表扫描 + 写操作”共存。
- 开启
slow_query_log并设置long_query_time=0，配合log_queries_not_using_indexes=ON - 用
SELECT * FROM performance_schema.events_statements_history WHERE sql_text LIKE '%UPDATE%' AND rows_affected > 1000找高影响 SQL - 对可疑语句跑
EXPLAIN FORMAT=JSON，重点关注key是否为NULL、rows是否远超预期、filtered是否极低
加索引就能解决？小心这些副作用
补索引是最常见解法，但不是万能膏药——加错索引反而让问题更隐蔽。
- 单列索引对
WHERE a=1 AND b=2效果有限，优先建联合索引(a,b)，顺序按选择性高低排 - 写多读少的表，高频
INSERT/UPDATE下，过多索引会拖慢性能，锁竞争可能从表级转为索引树 latch 竞争 -
LIKE '%abc'这种前导通配没法走索引，加索引也没用；得换全文索引或倒排结构
真正麻烦的从来不是“要不要加索引”，而是“加在哪、怎么验证它真起作用了”。一次 EXPLAIN 不够，得在压测中看 innodb_row_lock_waits 和 innodb_row_lock_time_avg 是否回落。
