UPDATE/DELETE未走索引会导致锁表，因InnoDB行锁加在索引上，无索引时需全表扫描并为每行加锁，REPEATABLE READ下还可能触发间隙锁，等效锁表。
为什么UPDATE/DELETE没走索引会导致锁表
MySQL 的行锁是加在索引上的，不是加在“数据行”本身。如果 WHERE 条件没命中任何索引，InnoDB 就无法定位目标行，只能扫描全表——对每条扫描到的记录都加行锁，最终效果等同于锁表（尤其在 REPEATABLE READ 下还可能触发间隙锁连带封锁）。这种场景下，一个慢更新就能让整张表的写操作排队等待。
- 用
EXPLAIN确认key字段非NULL，且rows值合理（别动不动几万） - 避免在索引列上用函数：
WHERE DATE(create_time) = '2026-04-01'→ 改成WHERE create_time >= '2026-04-01' AND create_time - 避免隐式类型转换：
WHERE user_id = '123'（user_id是INT）会丢索引 - 联合索引要注意最左匹配，
INDEX(a, b, c)能用于WHERE a = 1 AND b > 10，但不能用于WHERE b = 10
事务范围大是锁冲突的隐形推手
InnoDB 行锁遵循“两阶段锁协议”：锁在需要时加，但要等到 COMMIT 或 ROLLBACK 才释放。这意味着事务里任何一句没执行完的 SQL，前面所有加过的锁都还挂着——哪怕那句只是个 SELECT 或一次 RPC 调用。
- 把非数据库操作（HTTP 请求、日志写入、文件读取）全部移出事务块
- 不要在事务里做循环单条更新；批量操作优先用
INSERT ... VALUES (...), (...)或分批UPDATE ... WHERE id IN (?,?,?) - 高频更新热点行（如库存扣减）时，考虑拆成多行（
stock_shard_0~stock_shard_7）再聚合，或改用 Redis + Lua 预扣减 - 确认是否真需要
SELECT ... FOR UPDATE：有时先查后校验 + 乐观锁（UPDATE ... WHERE version = ?）更轻量
READ COMMITTED 能显著减少间隙锁冲突
默认的 REPEATABLE READ 隔离级别下，InnoDB 为防止幻读会自动加间隙锁（Gap Lock）和临键锁（Next-Key Lock），锁住索引区间而非单行——这在范围更新（如 UPDATE t SET status=1 WHERE created_at > '2026-04-01'）时极易扩大锁范围。而 READ COMMITTED 完全关闭间隙锁，只锁实际命中的记录行，大幅降低锁竞争。
- 业务能容忍不可重复读和幻读时，直接设会话级隔离：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED - 配合
binlog_format = ROW可保证主从复制一致性，无需担心 - 注意：RC 下快照读（普通
SELECT）仍可用，但当前读（SELECT ... FOR UPDATE）只看到已提交版本，锁也只加在当前匹配行上
监控锁等待比猜更有用
别靠日志报错或响应变慢才怀疑锁问题。真实瓶颈往往藏在“没人报错但就是慢”的请求里。
- 查当前阻塞链：
SELECT * FROM information_schema.INNODB_TRX看长时间未提交事务；再连performance_schema.data_locks和data_lock_waits查谁在等谁 - 看最近死锁：
SHOW ENGINE INNODB STATUS\G，重点读LATEST DETECTED DEADLOCK段 - 开慢查询日志（
long_query_time = 1），用pt-query-digest找出锁持有时间长的语句
真正难处理的从来不是“怎么加锁”，而是“为什么这个语句锁了它不该锁的行”。索引失效、事务拖沓、隔离级别误用，三者叠加时，锁冲突会指数级放大。盯住 EXPLAIN 输出和 INNODB STATUS 里的锁信息，比调参管用得多。
