无索引 WHERE 导致 UPDATE/DELETE 全表锁：因 InnoDB 需 next-key lock 覆盖聚簇索引，引发阻塞与高 trx_rows_locked；应建合适索引、避免隐式转换与 SET 中函数、慎用普通索引、改写 OR 条件、验证索引实际生效。
WHERE 字段没索引，UPDATE/DELETE 直接锁全表
MySQL 在执行 UPDATE 或DELETE时，如果 WHERE 条件字段没有索引，优化器大概率会放弃走索引扫描，转而用全表扫描——这时 InnoDB 没法精确锁定目标行，只能升级为 next-key lock 覆盖整个聚簇索引，实际效果接近表级锁。
常见错误现象：SHOW PROCESSLIST里看到语句状态长期卡在 Updating 或Deleting，同时其他 DML 被阻塞；INFORMATION_SCHEMA.INNODB_TRX里 trx_rows_locked 值异常高（几万甚至几十万）。
- 先用
EXPLAIN确认执行计划：重点看type是否为ALL或index，key列是否为NULL - 对
WHERE中出现的字段，优先建普通索引；复合条件时按WHERE中等值查询字段 → 最左前缀 → 范围查询字段顺序建联合索引 - 注意隐式类型转换：比如
user_id是BIGINT，但写成WHERE user_id = '123'，索引会失效
UPDATE SET 字段含函数或表达式，可能让索引失效
即使 WHERE 条件本身有索引，如果 SET 子句里对索引字段做了计算或函数调用，MySQL 在某些版本（尤其是 5.7 及以前）可能放弃使用该索引做定位，导致回表变多、锁范围扩大。
典型场景：给用户加积分时写 UPDATE users SET score = score + 10 WHERE uid = 123——只要uid 有索引，这句没问题；但若写成 UPDATE users SET score = IFNULL(score, 0) + 10 WHERE uid = 123，部分旧版本会跳过uid 索引。
- 避免在
SET中对WHERE所依赖的索引字段做函数包装，如UPPER()、TRIM()、DATE() - 用
EXPLAIN FORMAT=JSON查used_columns和used_indexes，确认索引是否被真正命中 - 批量更新时，宁可拆成
SELECT …… FOR UPDATE+ 应用层计算 +UPDATE …… SET score = ?，也不在 SQL 里做复杂表达式
唯一索引 vs 普通索引，锁行为差异很大
同样是 WHERE id = ?，如果id 是主键或 UNIQUE 索引，InnoDB 只锁匹配的那一条记录；但如果是普通索引（哪怕单列），它会锁住该索引项对应的 ** 所有聚簇索引记录 **，还可能带上间隙锁（gap lock），尤其在 RR 隔离级别下。
例如：ALTER TABLE orders ADD INDEX idx_status (status)，然后执行UPDATE orders SET paid = 1 WHERE status = 'unpaid'——哪怕只有 10 行满足，也可能锁住 status=’unpaid’ 区间内所有间隙，阻塞新插入。
- 高频 DML 的字段，尽量用
UNIQUE约束（或主键），而不是普通索引 - 非唯一索引条件慎用于大范围更新；必要时加
LIMIT分批，配合WHERE id > ?游标推进 - 测试时用
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS查谁在等谁，比猜更准
低版本 MySQL 对 OR 条件索引支持差，容易退化为全表扫描
MySQL 5.6 之前，WHERE a = 1 OR b = 2基本无法有效利用两个单独索引；5.7 开始支持 index merge，但代价估算不稳定，仍可能选错执行计划，最终触发全表扫描 + 全表锁。
错误现象：EXPLAIN显示 type: ALL，且Extra 里有 Using temporary; Using filesort 或空值。
- 改写为
UNION ALL：比如(SELECT …… WHERE a = 1) UNION ALL (SELECT …… WHERE b = 2 AND a != 1)，确保各自走索引 - 建联合索引覆盖所有 OR 字段，如
INDEX idx_a_b (a, b)，再用WHERE a = 1 OR (a IS NULL AND b = 2)这类技巧引导走索引（需业务逻辑允许） - 8.0.19+ 可用
SKIP LOCKED缓解并发更新冲突，但不解决锁范围问题
最易被忽略的一点：索引存在不等于生效。字符集不同（比如表用 utf8mb4，索引字段却是utf8）、统计信息过期、或者WHERE 里混用了 IS NULL 和=，都可能导致优化器弃用索引——别只看 SHOW INDEX，得用EXPLAIN 说话。
