INSERT唯一索引抢锁会触发MySQL死锁，因为多事务并发插入同一lock_key且持有其他行锁时形成循环等待；正确做法是抢锁与业务事务分离、独立连接执行、带超时重试及holder校验。
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 检测到死锁，回滚其中一个
这不是分布式锁设计失败，而是把锁表操作塞进了长事务里。
抢锁必须剥离出业务事务，且带超时重试
正确做法是：抢锁动作本身不能和业务逻辑共用一个事务，否则锁表失败会拖垮整个业务流程。必须做到“先抢锁，再开事务”：
- 用独立连接执行
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 < NOW()，作为兜底
真正容易被忽略的点在于：抢锁不是“调个函数就完事”，而是要把它当成一个有生命周期、有所有权、有超时契约的独立资源操作。一旦混进业务事务，或者忽略 holder 校验，就会把简单问题变成间歇性超时、偶发死锁、任务静默丢失的线上疑难杂症。
