MySQL存在"失效事务锁"需清理,因其innodb_lock_wait_timeout仅控制锁等待超时,不清理已卡死却未提交/回滚的悬挂事务,后者会长期持锁阻塞DML。MySQL 为什么会有"失效事务锁"需要清理MySQL 的 innodb_lock_wait_timeout 只控制等待锁的超时,不负责清理已卡死但未提交/回滚的事务。这类事务可能因应用崩溃、网络中断或程序逻辑 bug 导致长期持有锁却不释放,形成"悬挂事务"(zombie transaction),进而阻塞后续 DML。InnoDB 本身不会自动 kill 它们------得靠外部干预。查出正在运行却疑似失效的事务关键不是看"时间长",而是看"没进展还占着锁"。用以下查询定位:SELECT trx_id, trx_mysql_thread_id AS thread_id, trx_started, TIMEDIFF(NOW(), trx_started) AS duration, trx_state, trx_queryFROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND TIMEDIFF(NOW(), trx_started) > '00:10:00' AND trx_started < NOW() - INTERVAL 10 MINUTE;注意点:trx_state = 'RUNNING' 不代表健康------它可能是 sleep 状态下拿着锁不动,比如应用开了事务但忘了 commit别只依赖 trx_started 时间阈值,要结合业务场景判断:你的正常事务通常几秒?超过 2 分钟就值得怀疑trx_query 为空常见于空事务(BEGIN 后无操作),这种最危险:占锁、不干活、难察觉用 SQL + 定时任务安全 kill 悬挂事务不能直接在定时脚本里写 KILL,必须先确认、再执行、留日志。推荐用存储过程封装判断逻辑:DELIMITER CREATE PROCEDURE cleanup_zombie_trx()BEGIN DECLARE done INT DEFAULT FALSE; DECLARE v_trx_id VARCHAR(18); DECLARE v_thread_id BIGINT; DECLARE cur CURSOR FOR SELECT trx_id, trx_mysql_thread_id FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND trx_started \< NOW() - INTERVAL 5 MINUTE AND (trx_query IS NULL OR trx_query = ''); DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;\ OPEN cur;read_loop: LOOPFETCH cur INTO v_trx_id, v_thread_id;IF done THENLEAVE read_loop;END IF;INSERT INTO cleanup_log VALUES (NOW(), v_thread_id, v_trx_id, 'killed');KILL v_thread_id;END LOOP;CLOSE cur;END
MySQL如何配置自动清理失效事务锁_结合定时任务清理
z4424753262026-04-26 13:01
相关推荐
yuniko-n2 分钟前
【JVM】强、软、弱、虚引用reasonsummer32 分钟前
【办公类-04-05】20261030整理手机照片(华为手机助手导出照片到日期文件夹+批量添加四级文件夹+手动转移照片更名+更改三级文件夹合并汉字名称)Y001 小时前
PostgreSQL 权限管理踩坑记:从 42501 到默认权限和 RLSBD_Marathon1 小时前
【Python】初识迭代器呆萌很1 小时前
达梦(DM8)数据库常用SQL跟太阳说早安1 小时前
极简数据库SQL前端 贾公子2 小时前
第 5 章:Codex 从可运行程序到可交付工具杨云龙UP2 小时前
MySQL 主从复制管理:暂停、恢复、清理主从关系及命令执行位置gz927cool2 小时前
Python 全栈应用最佳实践完整指南智购科技智能售货柜2 小时前
顾客已经关门,视觉售货柜还在处理旧画面:延迟积压怎么查?~YH