UPDATE没走索引是Lock wait timeout exceeded主因：WHERE条件未命中索引导致全表扫描和意向锁堆积，应先用EXPLAIN验证执行计划，避免隐式类型转换、函数包裹等索引失效操作，并将非DB操作移出事务。
UPDATE没走索引？先查EXPLAIN再上线
90%的Lock wait timeout exceeded错误，根源是WHERE条件没命中索引，导致InnoDB退化为全表扫描+行级意向锁堆积。你看到的“卡住”，其实是其他事务在排队等一把本不该加的锁。
验证方法极简单：EXPLAIN SELECT * FROM orders WHERE user_id = '123'——如果type列是ALL或index，立刻停手。这不是性能问题，是锁模型崩塌的前兆。
- 隐式类型转换必踩坑：
user_id是BIGINT，但传入字符串'123'，索引直接失效；应改用user_id = 123 - 函数包裹必失效：
WHERE DATE(create_time) = '2026-10-01'→ 改成WHERE create_time >= '2026-10-01' AND create_time - 联合索引注意最左前缀：建了
(status, created_at)，但只查WHERE created_at > ?，照样全表扫
事务里混了HTTP调用或日志？锁就一直挂着
锁等待时间 = 事务从BEGIN到COMMIT之间的全部耗时。哪怕只更新100行，只要事务里夹着一次curl_exec、file_put_contents或MQ发送，锁就全程持有，其他并发请求只能干等。
高频出错模式：先SELECT FOR UPDATE查出一批ID，再循环处理业务逻辑，最后UPDATE——这中间的每毫秒都在锁表。
- 把非DB操作全部移出事务块：发消息、写文件、调第三方API，改用异步队列或最终一致性补偿
- 批量更新必须分片：
UPDATE orders SET status = 2 WHERE id IN (1,2,...,500)，每批控制在100–500行，COMMIT后立即释放锁 - 避免“查ID→算逻辑→再更新”三段式，改成单条
UPDATE ... WHERE id IN (SELECT id FROM ...)或带ORDER BY id的SELECT ... FOR UPDATE
隔离级别设成REPEATABLE READ？间隙锁正在悄悄锁死插入
默认REPEATABLE READ下，InnoDB对范围查询（如WHERE price BETWEEN 100 AND 500）加的是临键锁（Next-Key Lock），既锁记录又锁间隙。两个事务同时执行类似操作，极易因间隙重叠互相阻塞，哪怕更新的行完全不同。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
READ COMMITTED能切掉这块风险：它只加记录锁（Record Lock），语句执行完就释放不匹配的锁，且不锁间隙。代价是允许“不可重复读”，但多数业务场景（如订单状态变更、库存扣减）完全可接受。
- 连接级生效：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED - 全局配置需改
my.cnf：transaction_isolation = 'READ-COMMITTED'，注意binlog格式需为ROW - 别只看SQL文本，要结合索引判断：若
WHERE status = 'pending'没索引，即使降级到RC，仍会全表扫加锁
innodb_lock_wait_timeout设成120秒？用户已在前端刷新三次
把innodb_lock_wait_timeout从50秒调到120秒，不是延长容忍窗口，而是把失败延迟到更差的体验点——接口卡住2分钟才报错，用户早关页面了。真正该做的是让冲突快速暴露、快速失败、快速重试。
生产建议值：5–10秒。配合应用层重试（最多1–2次）和熔断，比硬扛更稳。
- 动态调整不如静态合理：Spring Boot里用
@Transactional(timeout = 5)比全局设120秒更可控 - 超时值≠处理耗时：它只是锁等待上限，实际事务执行时间应远低于此（比如3秒内完成更新+提交）
- 监控重点不是超时次数，而是
information_schema.INNODB_TRX里trx_state = 'RUNNING'且trx_started超5秒的长事务
锁问题最易被忽略的点，是把“SQL执行慢”和“锁等待久”当成一回事。前者优化索引就行，后者必须动事务结构——锁在哪加、加多久、加多少，全由事务边界和执行路径决定。一个没走索引的UPDATE，哪怕只影响0行，也会锁全表；一个含RPC的短事务，哪怕只改1行，也会拖垮整个业务。
