mysql执行复杂更新操作无响应_分析事务锁冲突与等待队列-mysql教程-PHP中文网

确认update卡住是否因锁：先查information_schema.innodb_trx找长时间running事务，再查innodb_lock_waits看阻塞链；结合trx_rows_modified判断是否可安全kill；避免全表扫描锁升级，确保where条件走索引。

mysql执行复杂更新操作无响应_分析事务锁冲突与等待队列

直接查 information_schema.INNODB_TRX 和 information_schema.INNODB_LOCK_WAITS，这是最准的起点。别先猜索引或网络问题，90% 的“无响应”更新卡在事务锁上。

SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED; 看谁的事务启动最早、运行最久，重点关注 TRX_STATE = 'RUNNING' 但长时间没提交的
搭配 SELECT * FROM information_schema.INNODB_LOCK_WAITS;，如果有记录，说明确实存在阻塞链：某事务在等另一个事务释放锁
注意 TRX_MYSQL_THREAD_ID，用它去 SHOW PROCESSLIST 找到对应连接，看它在执行什么 SQL、是否处于 Sleep 状态却还拿着事务

UPDATE 语句若 WHERE 字段没索引，InnoDB 会扫全表，每行加记录锁（Record Lock），再升级成间隙锁（Gap Lock）或临键锁（Next-Key Lock），锁范围远超预期——这会让后续很多操作排队等锁。

用 EXPLAIN FORMAT=JSON UPDATE ...（MySQL 8.0+）或先改写为 SELECT 加 EXPLAIN，确认 key 字段是否为 NULL
常见坑：对 TEXT / BLOB 字段做前缀索引后，在 WHERE 中用了 LIKE '%abc' 或函数如 UPPER(col)，索引失效
复合索引要注意最左匹配：INDEX(a,b,c) 支持 WHERE a=1 AND b>10，但不支持 WHERE b=10 单独出现

盲目 KILL 正在写数据的事务，可能触发长回滚（rollback），反而让锁持有更久。真正要杀的是那些“啥也没改却占着茅坑”的连接。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

查 INNODB_TRX 里的 TRX_ROWS_MODIFIED：值为 0 且 TRX_STATE = 'LOCK WAIT'，大概率是纯等待者；值很大且持续增长，说明它自己就是源头
别只看 PROCESSLIST 的 Time 列——sleeping 连接可能刚提交完，也可能刚开启事务还没执行任何语句，得结合 TRX_STARTED 和 TRX_ROWS_MODIFIED 综合判断
如果确认要 KILL，优先用 KILL QUERY <code>thread_id（只中断当前语句），而不是 KILL <code>thread_id（中断整个连接并触发回滚）

一次更新几十万行？InnoDB 会把所有涉及的页都加锁，其他查询/更新全得排队。这不是性能问题，是锁资源争抢问题。

按主键分段：比如 WHERE id BETWEEN 10000 AND 19999，每次最多 5000 行，配合 LIMIT 和 ORDER BY id 防止漏行
每批之间加短延时（如 100ms），给其他事务腾出执行窗口，避免锁队列越堆越长
避免在高峰期跑大更新；如果业务允许，把 UPDATE 拆成 SELECT + 应用层处理 + 多条小 UPDATE，控制锁粒度更细

锁冲突不是配置调参能绕开的，本质是事务边界和访问模式的问题。最容易被忽略的，是应用层没显式 COMMIT 或异常路径遗漏了 ROLLBACK——一个没关的事务，能让整张表堵死半小时。