怎么解决MySQL分布式任务抢锁死锁？-mysql教程-PHP中文网

INSERT唯一索引抢锁会触发MySQL死锁，因为多事务并发插入同一lock_key且持有其他行锁时形成循环等待；正确做法是抢锁与业务事务分离、独立连接执行、带超时重试及holder校验。

怎么解决mysql分布式任务抢锁死锁？

MySQL 分布式任务抢锁本身不会导致数据库级死锁，但“抢锁逻辑写错”或“锁释放不及时”会引发业务级僵死或数据库行锁冲突——本质是锁表操作与业务事务耦合不当。

为什么 INSERT 唯一索引抢锁会触发 MySQL 死锁？

很多人误以为 INSERT INTO distributed_lock 是原子的、绝对安全的，其实不然。当多个事务同时尝试插入同一 lock_key，且这些事务还持有其他行锁（比如正在更新订单或库存），就可能形成循环等待：

事务 A：已持 orders 表中 id=1001 的 X 锁，再执行 INSERT INTO distributed_lock → 因唯一冲突回滚前，仍短暂持有间隙锁或元数据锁
事务 B：已持 distributed_lock 表的意向锁（或自增锁），又去更新 orders 表 id=1001
两者互相等待对方释放锁 → InnoDB 检测到死锁，回滚其中一个

这不是分布式锁设计失败，而是把锁表操作塞进了长事务里。

抢锁必须剥离出业务事务，且带超时重试

正确做法是：抢锁动作本身不能和业务逻辑共用一个事务，否则锁表失败会拖垮整个业务流程。必须做到“先抢锁，再开事务”：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

用独立连接执行 INSERT ... ON DUPLICATE KEY UPDATE，不参与任何业务事务
检查返回影响行数：mysql_affected_rows() == 1 表示抢锁成功；== 0 表示已存在，需退避重试
设置固定重试上限（如 3 次）和指数退避（100ms → 300ms → 900ms），避免雪崩式重试
抢锁成功后，再用新连接开启业务事务，处理核心逻辑

示例伪代码逻辑：

if (insert_lock('task:sync_user_123', 'node-a', '2026-08-11 16:00:00') == 1) {
    // ✅ 抢锁成功，此时才启动业务事务
    begin_transaction();
    update_user_profile(...);
    commit();
    release_lock('task:sync_user_123', 'node-a');
} else {
    // ❌ 抢锁失败，sleep 后重试或直接放弃
}

锁表结构必须支持自动过期与持有者校验

只靠 expire_time 字段还不够。如果服务崩溃未释放锁，后续抢锁者需要能安全覆盖过期锁，但又不能误删别人正在用的有效锁。所以表结构要包含明确的持有者标识，并在抢锁/释放时严格校验：

建表时加 holder 字段：ALTER TABLE distributed_lock ADD COLUMN holder VARCHAR(64)
抢锁用 INSERT ... ON DUPLICATE KEY UPDATE 更新 holder 和 expire_time，但仅当原记录已过期才允许覆盖
释放锁必须同时匹配 lock_key 和 holder：DELETE FROM distributed_lock WHERE lock_key = ? AND holder = ?
额外加个定时清理任务（如每分钟）跑：DELETE FROM distributed_lock WHERE expire_time ，作为兜底