SELECT FOR UPDATE未走索引会锁全表，因InnoDB需全表扫描并对每个索引页加间隙锁；务必通过EXPLAIN确认索引使用，WHERE条件字段建合适索引并遵循最左匹配，优先用主键更新，避免函数操作导致索引失效。
SELECT FOR UPDATE 没走索引就等于锁全表
MySQL 的 SELECT FOR UPDATE 不是“锁行”，而是“锁索引记录 + 间隙”。没索引时，InnoDB 只能全表扫描，然后对每个扫描到的索引页加间隙锁——结果就是整张表被锁住，其他事务全部排队等待。
实操建议：
- 用
EXPLAIN看执行计划：如果type是ALL或index，说明没走有效索引 - WHERE 条件字段必须建索引，且注意最左匹配：比如联合索引
(user_id, status)，WHERE status = ?不会命中，但WHERE user_id = ? AND status = ?可以 - 避免在索引列上做函数操作：
WHERE DATE(create_time) = '2026-06-01'会让索引失效，改用create_time >= '2026-06-01' AND create_time < '2026-06-02'
UPDATE/DELETE 必须通过主键或唯一索引过滤
非主键/非唯一索引的 WHERE 条件，即使走了索引，也可能锁住多个索引记录及其间隙。而主键查询（如 WHERE id = 123）只锁单行记录本身，不带间隙锁（除非有范围条件），锁粒度最小、冲突最低。
实操建议：
- 高并发更新场景，优先用主键定位：
UPDATE order SET status = 2 WHERE id = 1001，而不是WHERE order_no = 'ORD20260609001'（除非order_no是唯一索引） - 批量更新别写
WHERE id IN (1,2,3,...,1000)—— 如果列表太长，可能触发临时表或扫描优化失败；拆成每批 50–100 个 ID，分多次提交 - 避免
UPDATE t SET col = col + 1 WHERE ...在大范围条件下使用，它会先读再写，延长锁持有时间；能预计算就预计算
覆盖索引能减少回表，间接缩短锁时间
即使 SELECT FOR UPDATE 走了索引，如果 SELECT 的字段不在该索引中，InnoDB 还得回表查聚簇索引，这个过程可能引发额外锁（尤其是二级索引+主键锁组合）。覆盖索引把所有需要字段都包含进来，一步到位。
实操建议：
- 例如业务只需
id和version做校验更新，建联合索引INDEX idx_id_version (id, version)，再写SELECT id, version FROM t WHERE id = ? FOR UPDATE - 不要
SELECT * FOR UPDATE，尤其表字段多、有 TEXT/BLOB 时，网络传输和内存开销大，拖慢整个事务 - 联合索引顺序要匹配查询模式：WHERE 条件字段放前面，SELECT 中的非 WHERE 字段放后面（用于覆盖）
事务里用错索引顺序，锁范围可能翻倍
InnoDB 的间隙锁范围取决于索引扫描路径。同样一个 WHERE 条件，因索引结构不同，锁住的间隙可能差十倍。比如 WHERE status = 1 AND user_id = 100 在 (status, user_id) 索引下，可能锁住整个 status = 1 的所有间隙；换成 (user_id, status)，就只锁 user_id = 100 对应的那几行及间隙。
实操建议：
- 高频更新的字段（如
user_id、order_id）尽量放在联合索引最左侧 - 低基数字段（如
status、type）别单独建索引，也别放联合索引最左；否则容易触发索引跳跃扫描，扩大锁范围 - 用
SELECT * FROM performance_schema.data_locks查看当前事务实际锁了哪些记录和间隙，验证索引效果
索引不是加了就万事大吉，同一组字段，顺序一变、类型一换、查询写法一偏，锁行为就可能从“精准单行”变成“扫半张表”。真正关键的是让每一句 SELECT FOR UPDATE 或 UPDATE 都明确知道自己在哪个索引上跳哪几步——这比堆索引数量重要得多。
