update超时主因是锁等待而非sql性能，常见于行锁、mdl锁或隐式锁阻塞，需优先查活跃事务、锁等待链及元数据锁，再确认索引是否生效。

UPDATE超时不是SQL慢，大概率是锁住了

执行UPDATE卡住、超时、没报错但数据没变——十有八九不是语句写得差，而是被别的事务或连接锁住了。MySQL的行级锁只在事务中生效，且依赖索引；一旦WHERE条件没走索引，或者有长事务没提交，UPDATE就会挂在那里等锁，直到innodb_lock_wait_timeout（默认50秒）触发报错Lock wait timeout exceeded。

但注意：如果卡住时间远超50秒还不报错，说明它根本没进入行锁等待阶段——可能堵在MDL锁（比如有人正在ALTER TABLE）、复制线程、备份工具（如mydumper），甚至SHOW PROCESSLIST里能看到Waiting for table metadata lock。

• 先查当前活跃事务：SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - TRX_STARTED) > 60;
• 再看锁等待链（MySQL 8.0+）：SELECT * FROM performance_schema.data_lock_waits;
• 查MDL锁：SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'TABLE';

WHERE条件没走索引，UPDATE会退化成全表扫描+锁表

UPDATE慢，第一反应不该是“优化SQL”，而是确认WHERE字段有没有有效索引。特别是id IN (7,9,6,8,3,5)这类写法，看着短，但如果id字段没索引，MySQL就得全表扫一遍再逐行判断，不仅慢，还会对所有扫描过的行加意向锁——高并发下极易引发锁冲突。

用EXPLAIN SELECT *模拟执行计划（MySQL不支持直接EXPLAIN UPDATE）：

EXPLAIN SELECT * FROM free_settlement_apply_invoice WHERE id IN (7,9,6,8,3,5);

重点看type列：要是ALL，就是全表扫描；const或range才算走了索引。

• 主键或唯一索引字段用=或IN，基本没问题；但组合索引要注意最左匹配
• 字段类型不一致会触发隐式转换，比如status VARCHAR却写WHERE status = 1，索引失效
• IN列表超过几千个值时，优化器可能放弃使用索引，改用临时表或全表扫描

DBeaver里执行UPDATE超时，先看是不是连接堆积

你在DBeaver点一下就超时，但命令行里秒执行？别急着怪SQL——DBeaver默认保持长连接，每次执行都复用连接。如果之前某次查询没关掉、或脚本里漏了COMMIT，连接就一直挂着SLEEP状态，占着连接数和潜在锁资源。

SHOW PROCESSLIST;一跑，常看到一堆Host是你本机IP、Command是Sleep、Time几百上千秒的线程。这些不是“空闲”，而是未释放的事务上下文，可能还持有着行锁或间隙锁。

• 杀掉可疑线程：KILL <thread_id>;</thread_id>（比如KILL 36590983;）
• 别只关DBeaver窗口——要关掉所有连数据库的应用，包括后台Java服务、定时任务、甚至浏览器里的phpMyAdmin
• DBeaver设置里把Connection timeout和Query timeout调短（比如30秒），避免无意义等待
• 开发环境建议设autocommit=1，避免手滑忘COMMIT导致锁残留

隐式锁会让UPDATE“静默卡住”，监控里还看不到

这是最难排查的一类：SHOW PROCESSLIST里State是updating，INNODB_TRX里却查不到对应事务，data_lock_waits也为空。典型表现就是UPDATE挂住、不报错、也不返回——其实是InnoDB的“隐式锁”在作祟。

比如一个事务刚INSERT了一行但没提交，另一事务立刻UPDATE同一行，InnoDB不会马上加锁，而是在读取/修改时才现场判断并转为显式锁。这期间监控看不到锁记录，但实际已阻塞。

• 强制暴露锁行为：BEGIN; SELECT * FROM tbl WHERE id = ? FOR UPDATE; UPDATE tbl SET ... WHERE id = ?; COMMIT;
• 检查是否有未提交的INSERT，尤其注意唯一键冲突后回滚不干净的情况
• 避免在同一个事务里混用INSERT和UPDATE操作同一张表，拆成独立小事务
• 高并发场景下，优先用SELECT ... FOR UPDATE显式加锁，而不是依赖UPDATE WHERE的隐式行为

真正卡住的时候，往往不是语法或逻辑问题，而是锁状态、连接生命周期、索引路径这三个层面的细节没对齐。查PROCESSLIST比调优SQL更管用，看INNODB_TRX比猜执行计划更直接。最容易被忽略的是：你以为只是执行一条UPDATE，其实背后牵扯着连接池、事务隔离级别、元数据锁、甚至备份工具的持有状态。