17370845950

不能直接用 INSERT ... ON DUPLICATE KEY UPDATE 做分布式锁，因其无法区分锁被占用还是已过期，且 UPDATE 会覆盖他人有效锁，缺乏原子性校验；正确方案是 SELECT ... FOR UPDATE 加显式事务或 INSERT + SELECT 双检。

为什么不能直接用 INSERT ... ON DUPLICATE KEY UPDATE 做分布式锁

很多人第一反应是靠唯一索引冲突来“抢锁”，比如建一张 lock_table，主键或唯一索引为 lock_key，然后执行：

INSERT INTO lock_table (lock_key, owner, expire_at) VALUES ('order_123', 'svc-a', NOW() + INTERVAL 30 SECOND) ON DUPLICATE KEY UPDATE owner = VALUES(owner), expire_at = VALUES(expire_at);

但问题在于：这只能告诉你“插入失败”，无法区分是「锁已被别人持有」还是「锁已过期但未清理」。更麻烦的是，ON DUPLICATE KEY UPDATE 会触发更新，导致你误认为自己拿到了锁，而实际只是覆盖了别人的过期记录——没有原子性校验。

真正可用的行锁方案：用 SELECT ... FOR UPDATE + 显式事务

核心思路是把锁状态存在一行里，靠 MySQL 的当前读和行级锁保原子性。要求表有主键（比如 lock_key），且该行必须预先存在（可初始化一批常用锁 key，或首次请求时用 INSERT IGNORE 补）：

BEGIN;
SELECT * FROM lock_table WHERE lock_key = 'order_123' FOR UPDATE;
-- 检查返回行的 expire_at 是否已过期
-- 若已过期，UPDATE 它并继续；否则说明被占用，直接 ROLLBACK
UPDATE lock_table SET owner = 'svc-a', expire_at = NOW() + INTERVAL 30 SECOND WHERE lock_key = 'order_123' AND (expire_at < NOW() OR expire_at IS NULL);
-- 检查 ROW_COUNT() === 1？是则成功，否则 
ROLLBACK
COMMIT;

注意点：

• FOR UPDATE 必须在事务内，且后续操作要基于同一行
• UPDATE 的 WHERE 条件必须包含过期判断，否则可能覆盖有效锁
• 应用层必须检查 ROW_COUNT()，MySQL 不报错，只返回影响行数
• 务必设超时（客户端连接超时、事务超时、锁本身 TTL），避免死锁雪崩

唯一索引方案的可行变体：用 INSERT + SELECT 双检

如果不想预建行，可以用两阶段唯一约束法，但必须加 SELECT 验证：

BEGIN;
-- 先查是否存在未过期锁
SELECT owner FROM lock_table WHERE lock_key = 'order_123' AND expire_at > NOW();
-- 若有结果，说明锁被占，ROLLBACK
-- 若无结果，尝试插入（唯一索引 lock_key）
INSERT INTO lock_table (lock_key, owner, expire_at) VALUES ('order_123', 'svc-a', NOW() + INTERVAL 30 SECOND);
-- 若 INSERT 报错 1062 Duplicate entry，说明并发插入中有一方失败，需重试或放弃
COMMIT;

关键细节：

• 两次查询之间存在窗口，所以失败后不能直接认为“锁不可用”，得回查一次确认
• 必须捕获 1062 错误码，其他错误（如连接中断）要按异常处理
• INSERT 不带 ON DUPLICATE KEY，否则失去“是否抢到”的判断依据
• 不推荐高并发场景，冲突率上升会导致大量事务回滚

容易被忽略的三个落地细节

真实部署时，光逻辑对还不够：

• 锁表必须用 INNODB 引擎，MyISAM 不支持行锁和事务
• 所有 SQL 要走相同索引路径，避免锁升级成表锁——确保 WHERE lock_key = ? 走的是主键或唯一索引
• 客户端必须设置 innodb_lock_wait_timeout（比如 5 秒），而不是依赖默认 50 秒，否则一个卡住的事务会让后续全部排队挂起

另外，不要试图用 GET_LOCK() 这类 MySQL 会话级函数，它不跨连接，根本不是分布式锁。