mysql分布式锁不能用事务内select...for update代替，因其仅事务内可见；必须用带过期时间的原子操作（如insert+唯一索引）实现跨节点加锁-校验-释放闭环，且释放需条件删除防误删。
MySQL 分布式锁不能在事务里用 SELECT ... FOR UPDATE 代替
很多人以为开个事务，再 SELECT ... FOR UPDATE 查一行就等于拿到了分布式锁——不是的。它只对当前事务可见，别的服务实例根本感知不到这个“锁”，更不会阻塞。真正的分布式锁必须跨进程、跨节点生效，靠数据库单行记录模拟的话，得自己实现加锁-校验-释放的闭环，且不能依赖事务自动回滚来清理锁。
常见错误现象：Deadlock found when trying to get lock 频发，或两个服务同时写入同一条业务数据；更隐蔽的是锁没释放（比如应用崩溃），导致后续所有请求卡死。
- 加锁必须用原子操作：
INSERT INTO lock_table (key, owner, expire_at) VALUES (?, ?, ?)，靠主键/唯一索引冲突判断是否抢锁成功 - 锁必须带过期时间（
expire_at字段），不能只靠事务生命周期 - 释放锁时必须校验
owner和expire_at，防止误删别人持有的锁 - 不要在事务中执行加锁逻辑——否则锁的生命周期被事务绑架，异常回滚会导致锁消失，但业务可能已部分执行
用 GET_LOCK() 函数要注意作用域和连接生命周期
GET_LOCK() 是 MySQL 自带的命名锁函数，轻量、快，但它绑定在**连接级**：一个连接调用 GET_LOCK('order_123', 10) 成功后，只有这个连接能 RELEASE_LOCK()；连接断了会自动释放。这意味着你不能在连接池环境下直接用，因为业务代码拿到的很可能不是同一个物理连接。
使用场景：适合短时、单机多线程协调（比如同一台应用服务器内多个线程争一个资源），不适合微服务间协调。
- 必须确保加锁和释放发生在同一个数据库连接上，不能“借连接加锁、还连接释放”
-
GET_LOCK()不支持超时自动续期，长时间操作需手动SELECT IS_USED_LOCK('order_123')检查是否还在 - 不同 MySQL 实例之间不共享锁状态，跨库部署时完全无效
- 高并发下
GET_LOCK()本身有性能瓶颈，压测时容易出现响应延迟突增
事务中修改数据前，必须先完成分布式锁获取并验证有效性
典型错误顺序是：开启事务 → 查询业务数据 → 判断能否操作 → 再去尝试加分布式锁。这中间存在竞态窗口：A 刚查完，B 就抢到锁并改完了，A 还按旧状态继续执行，事务提交时就覆盖了 B 的结果。
正确顺序只能是：先用外部机制（如 Redis 或独立锁表）抢锁 → 抢到后再开启事务 → 读取+修改+提交 → 最后释放锁。锁的持有期要严格包裹住整个事务执行过程。
- 锁的 key 必须包含业务维度标识，比如
"stock_item_456"，不能只用通用名"stock_lock" - 加锁失败必须立刻返回，不能重试后继续走事务（否则重试间隔里状态已变）
- 如果锁带租约（如 Redis 的 SET NX PX），应用层需启动守护线程或定时任务续期，避免事务未结束锁先过期
- 事务内不要做 HTTP 调用、文件 IO 等长耗时操作，否则锁占用时间不可控
释放锁失败会导致“幽灵锁”，比加锁失败更危险
加锁失败顶多是请求拒绝，而释放失败会让锁一直挂着——后续所有请求都会被拦在外面，系统进入假死状态。这个问题在异常路径（如网络超时、JVM OOM、容器被杀）下极易发生，且很难监控。
最容易被忽略的点：释放锁的操作本身也得具备幂等性和可靠性。不能只靠 try-finally 做释放，因为 finally 块也可能因线程中断或 Kill -9 失效。
- 推荐方案：锁记录里存
owner（如 UUID）+expire_at，释放时用DELETE FROM lock_table WHERE key = ? AND owner = ? AND expire_at > NOW()，靠数据库原子性保证安全 - 不要用
UPDATE ... SET locked = 0这类非条件更新，无法防止误清锁 - 生产环境建议加锁表的定期巡检任务，扫描过期但未释放的锁并告警
- 如果用 Redis 实现，优先选 Lua 脚本封装释放逻辑，避免 GET+DEL 两步造成竞态
真正难的不是怎么加锁，而是怎么让锁在各种异常组合下依然可预测地失效或释放。网络分区、GC 停顿、数据库主从延迟、容器漂移……这些都会撕裂你设计的锁语义。别假设“只要代码写了释放就一定会执行”。
