MySQL GET_LOCK()：一个被误解的“分布式锁”工具
MySQL GET_LOCK() 能不能当分布式锁用
开门见山地说，直接把它当作生产级的分布式锁来用，风险极高。这个函数的设计初衷，其实是为了在单个MySQL实例内部，进行一些轻量级的协作控制。为什么这么说？原因很具体：首先，GET_LOCK() 是会话级别的，一旦数据库连接断开，锁就自动消失了；其次，它没有TTL（生存时间）的概念，无法自动续期或超时释放；再者，它缺乏公平的队列机制，谁先抢到算谁的；最关键的一点，由于锁信息不会复制到从库，在主从延迟的场景下，从库根本感知不到主库上的锁状态。
一个典型的踩坑现象就是：在主库执行 SELECT GET_LOCK('order_123', 0) 成功返回1，但另一个应用在从库查询 IS_USED_LOCK('order_123') 时，得到的却是 NULL。这可不是程序bug，而是架构上的天然限制。
- 适用场景：同一应用进程内的多线程，需要协调访问某个本地资源时，比如防止重复初始化某张内存表。
- 不适用场景：任何跨服务、跨机器、需要持久化或强一致性的业务锁场景。
- 额外提醒：
timeout参数的单位是秒，它只控制获取锁时的等待时长，而非锁的持有时间。锁一旦到手，就会一直占着，直到你显式释放或者连接关闭。
GET_LOCK() 和 RELEASE_LOCK() 必须配对使用
这个问题看似基础，却经常被忽略。很多人只记得调用 GET_LOCK()，却忘了释放，结果导致锁长期滞留，后续的所有请求都卡在超时上。必须明确一点：MySQL不会关心你的业务逻辑是否执行完毕，它只认连接的生命周期。
因此，实操中有几个关键点必须牢记：
- 连接一致性：
GET_LOCK()和RELEASE_LOCK()必须在同一个数据库连接中调用，跨连接操作是无效的。 - 异常兜底：务必使用
try/finally或类似机制（如Go的defer、Python的contextlib.closing），确保即使在程序异常时，锁也能被可靠释放。 - 警惕连接池：别指望连接池自动关闭连接来清理锁。连接被复用后，上面挂着的旧锁依然存在，新业务可能会误以为自己成功拿到了锁，从而引发数据混乱。
下面是一个Python的示例，展示了正确的使用姿势：
conn = get_db_conn()
cursor = conn.cursor()
try:
cursor.execute("SELECT GET_LOCK(%s, 30)", ("task_batch_456",))
locked = cursor.fetchone()[0]
if not locked:
raise RuntimeError("failed to acquire lock")
# 在这里执行真正的业务逻辑
finally:
cursor.execute("SELECT RELEASE_LOCK(%s)", ("task_batch_456",)) # 必须执行
conn.close()
锁名要注意作用域和特殊字符
锁名可不是随便起的字符串。GET_LOCK() 内部会将其作为全局哈希键，这意味着，只要名字相同，哪怕来自毫不相干的业务模块，也会产生互斥。
- 命名禁忌：避免使用纯数字（如
"123"）或包含空格、斜杠等特殊字符的名字（如"user/1001"）。虽然语法上允许，但极易与其他系统生成的锁名冲突。 - 推荐格式：采用
"服务名:资源类型:标识ID"这样的层级结构，例如"billing:invoice:789"，清晰且不易冲突。 - 长度限制：锁名最大长度为64个字符。超过部分会被静默截断，这可能导致两个不同的长锁名在哈希后变成相同的键，比如
"a"*65和"a"*66最终都会被当作64个“a”来处理。 - 大小写敏感：需要注意，
"Order123"和"order123"在MySQL看来是两个完全不同的锁。
替代方案比硬扛 GET_LOCK() 更靠谱
如果业务确实需要跨进程、能容错的分布式锁，那么更好的选择是使用专门的外部工具。让数据库干它最擅长的事，而不是勉强它充当一个不称职的锁服务。
- 简单场景：可以考虑使用
INSERT ... SELECT ... FOR UPDATE在业务表上加行锁。利用唯一索引保证互斥，锁随事务结束自动释放，简单直接。 - 中等规模：Redis的
SET key value EX seconds NX命令是更成熟的选择。配合Lua脚本实现原子化的释放逻辑，社区方案成熟，可靠性高。 - 复杂协调：对于需要严格顺序和协调的复杂场景，ZooKeeper或etcd是专业之选。它们原生的临时节点和Watch机制，为分布式锁提供了语义更清晰的实现基础。
话说回来，如果硬要在 GET_LOCK() 上打补丁，比如增加心跳续期、轮询从库验证状态……最终写出的代码，其复杂度和维护成本可能比直接换用Redis还要高，而且依然绕不开主从不一致这个根本性的架构缺陷。
