SQL中用布尔值实现乐观锁可行吗？布尔字段互斥锁代码是否安全？

结论：你的方案是安全的，能保证同一时间只有单个客户端持有锁 #

为什么这个方案靠谱？ #

关系型数据库的UPDATE语句是原子执行的：当多个客户端同时执行这条更新语句时，数据库会自动给目标行加行级锁，只有第一个成功匹配lock_field = 0 AND mutex_id = 17的会话能修改行，返回受影响行数1；其他会话因为lock_field已经被改成1，匹配不到任何行，返回0。这个过程完全由数据库的锁机制保证，不会出现多个客户端同时拿到锁的情况。

要避开的坑 #

• 锁卡死：如果持有锁的客户端突然崩溃、进程挂掉，没来得及执行释放锁的UPDATE，lock_field会一直是1，后续所有客户端都拿不到锁。解决办法：
  • 加个过期时间字段，比如lock_expire，拿锁的时候同时设置lock_expire = NOW() + INTERVAL 5 MINUTE，其他客户端可以在拿锁时判断：UPDATE ... WHERE (lock_field = 0 OR lock_expire < NOW()) AND mutex_id = 17，确保锁过期后能被抢占
  • 后台加个定时任务，定期清理超时未释放的锁
• 重试逻辑：第一次拿锁失败就直接抛异常太激进，建议做指数退避重试（比如第一次等100ms，第二次200ms，最多重试5次），避免不必要的失败
• 事务别拖太长：如果拿锁的操作放在一个大事务里，事务没提交前，其他客户端看不到锁状态的变化（和隔离级别有关），尽量把拿锁、释放锁做成独立的短操作，或者尽快提交事务

额外说明：这不是传统乐观锁 #

你实现的是基于数据库行锁的悲观互斥锁，而乐观锁的思路是“先做操作，最后校验版本是否被别人改了”（比如用版本号：UPDATE ... WHERE version = 旧版本号，失败就说明并发冲突）。你的方案适合必须严格互斥的场景，乐观锁更适合冲突概率低、想尽量减少锁开销的场景。

内容的提问来源于stack exchange，提问作者BlueBiscuit