无索引的WHERE条件导致事务持锁更久，是因为InnoDB需全表扫描并为所有扫描行及间隙加锁，锁范围扩大、扫描变慢，事务持续时间延长；必须为UPDATE/DELETE中定位目标的字段（如user_id、order_no）及高频复合查询字段（如status, created_at）建立合适索引。
为什么无索引的 WHERE 条件会让事务持锁更久？
InnoDB 的行锁不是“按数据内容加”，而是“按索引路径加”。没有索引时，UPDATE 或 DELETE 只能全表扫描，过程中会对所有扫描到的行（甚至间隙）加锁——这不是几行，而是成百上千行或整个表。锁范围越大、扫描越慢，事务自然拖得越长。你看到的 Lock wait timeout exceeded 或大量 innodb_row_lock_time_avg 升高，往往就从这里开始。
哪些字段必须加索引才能缩短持锁时间？
重点不是“所有 WHERE 字段”，而是“事务中用于定位修改目标的字段”。尤其是：
-
UPDATE/DELETE语句的WHERE条件字段，比如WHERE user_id = ?、WHERE order_no = ? - 如果业务逻辑中常通过非主键字段更新（如状态、时间范围），且并发高，必须为该字段建唯一索引或普通索引
- 复合条件要符合最左前缀，例如常用
WHERE status = ? AND created_at > ?，应建INDEX idx_status_created (status, created_at)，而非单独建两个单列索引
反例：UPDATE orders SET status = 2 WHERE created_at —— 若 created_at 无索引，会锁住数万行，事务可能卡住数秒。
EXPLAIN 是不是走索引，比“有没有建”更重要
建了索引不等于被用上。常见失效场景包括：
- 在索引列上用函数：
WHERE DATE(created_at) = '2025-01-01'→ 改成WHERE created_at >= '2025-01-01' AND created_at - 隐式类型转换：
WHERE user_id = '123'（user_id是INT）→ 改成WHERE user_id = 123 - 使用
OR连接非索引字段：WHERE a = 1 OR b = 2，若b无索引，可能放弃走索引
每次上线新 SQL，务必跑一遍 EXPLAIN FORMAT=TREE，确认 rows_examined 是个位数或百位数，而不是十万级。
主键更新永远是最优解，但别迷信“覆盖索引”能省锁
用主键更新（WHERE id = ?）是持锁最短的方式：只锁一行，且不触发间隙锁。但注意：
- 覆盖索引（
SELECT a,b FROM t WHERE c=?，且a,b,c都在索引里）能避免回表，但它对UPDATE/DELETE的锁范围没影响——锁还是加在聚簇索引（即主键）上 - 想真正减锁，核心是让 WHERE 快速命中主键或唯一索引，而不是“查得快”
- 如果业务无法改用主键更新，至少确保 WHERE 字段有唯一索引；重复值越多，锁的行数越多，风险越高
真正容易被忽略的是：索引优化不是一次性动作。当 WHERE 条件随业务迭代变化（比如新增按手机号更新订单），旧索引立刻失效，而开发往往只测功能，不验执行计划。
