不能直接用 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 会话级函数，它不跨连接，根本不是分布式锁。 
