唯一索引+显式过期时间是最稳的分布式锁方案，因锁状态持久化到磁盘、原子性强、不依赖会话或隔离级别；需建UNIQUE KEY、校验错误码、用lock_id防误删、清理过期锁并用服务端时间。
能，但必须用唯一索引 + 显式过期时间，不能只靠 GET_LOCK() 或裸 SELECT ... FOR UPDATE。
为什么唯一索引 INSERT 是最稳的方案
MySQL 的 GET_LOCK() 是会话级内存锁，服务重启就丢，集群里各节点看到的锁状态不一致；SELECT ... FOR UPDATE 看似直观，但一旦 lock_key 字段没走索引，就会升级成表锁——所有后续加锁请求全被堵死，数据库连接池迅速耗尽。
唯一索引方案把“是否已上锁”这个事实固化在磁盘行里，插入成功即获锁，失败即冲突，原子性由 MySQL 保证，不依赖事务隔离级别，也不怕连接中断。
- 必须建
UNIQUE KEY（不是普通索引），且字段类型要和查询条件完全一致（比如VARCHAR(64)就不能传 65 字符） -
expire_time字段不可省：它不是装饰，而是防死锁的兜底，后续靠定时任务或应用层轮询清理过期锁 - 不要用自增
id当主键再加唯一索引，直接把lock_key设为PRIMARY KEY更简洁、更少 IO
INSERT 失败时到底抛什么错误？
不是所有“插入失败”都代表锁已被占。你得区分三种情况：
-
1062 Duplicate entry 'xxx' for key 'uk_lock_key'→ 正常冲突，锁已被持 -
1205 Deadlock found→ 行锁等待超时，需重试（但概率低，因唯一索引冲突不走锁等待路径） -
2006 MySQL server has gone away或连接超时 → 不是锁问题，是网络或连接池配置不当
代码里不能只捕获 IntegrityError 就认为抢锁失败，得 inspect 错误码。Python 用 exc.args[0]，Java 用 SQLException.getSQLState() 或 getErrorCode() 判断。
释放锁时 DELETE 必须带业务标识校验
只写 DELETE FROM distributed_lock WHERE lock_key = 'order:1001' 是危险的——如果 A 节点获取锁后卡住，B 节点等超时后自己插入同名锁（靠 ON DUPLICATE KEY UPDATE 或先删后插），A 恢复后一删就把 B 的锁干掉了。
正确做法是让每次获取锁都生成唯一 lock_id（如 UUID），插入和删除都带上它：
INSERT INTO distributed_lock (lock_key, lock_id, expire_time)
VALUES ('order:1001', 'a1b2c3d4', DATE_ADD(NOW(), INTERVAL 10 SECOND));
DELETE FROM distributed_lock WHERE lock_key = 'order:1001' AND lock_id = 'a1b2c3d4';
这样释放操作变成“认人不认锁”，避免误删。
过期锁清理不能只靠定时任务
定时任务（比如每分钟扫一次 expire_time < NOW()）有延迟窗口，期间新请求仍可能因唯一索引冲突被拒，造成短暂不可用。
更稳妥的做法是在获取锁前主动清理：
- 执行
DELETE FROM distributed_lock WHERE lock_key = ? AND expire_time < NOW()（注意：这个语句本身不加锁，无风险） - 再执行
INSERT尝试获锁
两次操作不在同一事务里没关系——清理只是优化，不影响原子性；哪怕清理完瞬间另一个节点插入了，你的 INSERT 仍会因唯一约束失败，逻辑不变。
真正容易被忽略的是：expire_time 必须用 NOW() 计算，不能用客户端时间，否则时钟漂移会导致锁提前或延后失效。
