EXPLAIN可确认是否走索引，避免全表扫描锁表；type为ALL或index说明未命中有效索引；WHERE字段须建索引，联合索引需最左匹配，索引列上禁用函数。
EXPLAIN确认是否走索引，避免全表扫描锁全表
没走索引的 SELECT FOR UPDATE 或 UPDATE 会触发全表扫描，InnoDB 对每个扫描到的索引页加间隙锁，实际效果等同于锁整张表。这不是“慢”，而是“锁得多、堵得死”。
实操建议：
- 执行
EXPLAIN SELECT * FROM orders WHERE order_no = 'ORD20260928'，重点看type字段：若为ALL或index，说明未命中有效索引 - WHERE 条件字段必须建索引；联合索引要遵循最左匹配，比如有
INDEX idx_user_status (user_id, status)，WHERE status = 'paid'不会命中，但WHERE user_id = 123 AND status = 'paid'可以 - 避免在索引列上用函数：
WHERE DATE(create_time) = '2026-09-28'会让索引失效，改用create_time >= '2026-09-28' AND create_time
优先用主键或唯一索引更新，缩小锁粒度
非主键条件即使走了索引，也可能锁住多个索引记录 + 间隙；而主键查询（如 WHERE id = 1001）只锁单行记录本身（无间隙锁，除非带范围），冲突概率最低。
实操建议：
- 高并发更新优先走主键：
UPDATE order SET status = 3 WHERE id = 1001，而不是WHERE order_no = 'ORD20260928001'（除非order_no是唯一索引） - 批量更新别用超长
IN列表：WHERE id IN (1,2,...,1000)容易触发执行计划退化或临时表，拆成每批 50–100 个 ID 分多次提交 - 避免
UPDATE t SET col = col + 1 WHERE ...在大范围条件下使用——它先读再写，延长锁持有时间；能预计算就预计算
用覆盖索引减少回表，间接缩短锁时间
即使 SELECT ... FOR UPDATE 走了索引，如果所查字段不在该索引中，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 字段放后面（用于覆盖）
事务内SQL顺序影响锁持有数量
先 UPDATE 后 INSERT 会更久锁表，因为 UPDATE 提前加了行锁/间隙锁，后续 INSERT 需在已持锁范围内做唯一键检查；反过来，INSERT 先执行只加轻量插入意向锁，再 UPDATE 锁更少、时间更短。
实操建议：
- 把不依赖其他操作结果的写入（如日志记录、状态初始化）放在事务最前面
- 需要查旧值再更新的逻辑（如
SELECT ... FOR UPDATE后紧跟UPDATE）必须前置，但“顺手查个日志”这类操作应挪到事务外异步做 - 幂等写入场景下，想确保不冲突，可先
SELECT ... FOR UPDATE唯一键所在行（哪怕查不到），再INSERT——这能阻塞其他事务同时插入相同值
锁持有数量不是靠“猜”，而是由执行计划决定的。一个没走索引的 WHERE 条件，或者一个没设计好的联合索引顺序，都可能让本该锁 1 行变成锁 1000 行。真正关键的不是 SQL 写得多漂亮，而是每一行执行时，MySQL 底层到底锁了哪些索引记录和间隙。
