无索引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说话。
