MySQL 锁定服务与 GET_LOCK 的命名粒度有什么区别

MySQL 里有两套容易被混为一谈的应用级锁接口：锁定服务（Locking Service）和 GET_LOCK()。它们都跟当前会话绑定，也都不会因为事务提交或回滚自动释放，但“锁名到底由什么组成”并不一样。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/locking-service.html

先给结论：锁定服务把 namespace 与 lock name 组合成唯一标识，还能选择读锁或写锁；GET_LOCK() 只有一个字符串名，锁始终是排他的。需要多应用隔离、读写并发语义时优先考虑锁定服务；只是让多个连接围绕一个业务名互斥时，GET_LOCK() 更直接。

一、命名粒度：锁定服务是二元标识，GET_LOCK 是单字符串

锁定服务的标识可以写成 (namespace, lock_name)。例如，billing 命名空间里的 daily_close，和 reporting 命名空间里的同名锁不是同一个锁。命名空间的作用是让不同应用能够复用短锁名而不互相撞车。

GET_LOCK() 的键只有传入的 str。团队通常会把应用名、环境和业务对象拼进字符串：

-- 锁定服务：namespace 与 lock name 分开表达隔离边界
SELECT service_get_write_locks('billing', 'daily_close', 0);

-- GET_LOCK：把隔离信息写进一个完整字符串，格式由应用自己约定
SELECT GET_LOCK('billing:prod:daily_close', 0);

两种写法在“避免不同模块误用同一个名字”这个目标上相似，但语义仍不同。锁定服务的命名空间是接口的一部分，监控时会单独出现在 OBJECT_SCHEMA；GET_LOCK() 的前缀只是字符串约定，任何调用方只要传入相同字符串就能参与竞争。

二、锁模式、释放范围和监控字段也不同

锁定服务有两种模式：读锁是共享的，同一标识可以被多个会话同时持有；写锁是排他的，会阻挡同标识上的读锁和写锁。SQL 接口对应 service_get_read_locks()、service_get_write_locks() 和 service_release_locks()。

GET_LOCK() 没有读写模式，拿到的就是同名排他锁。它可以在同一会话中持有多个不同名字的锁，甚至重复获取同一个名字；因此释放时不能只凭“事务结束了”来推断已经放锁：

-- 读锁允许同一标识上的其他读者共享
SELECT service_get_read_locks('reporting', 'refresh_view', 5);

-- 写锁需要排他使用；超时参数 0 表示不等待
SELECT service_get_write_locks('reporting', 'refresh_view', 0);

-- 锁定服务按 namespace 释放当前会话在该命名空间中的锁
SELECT service_release_locks('reporting');

-- GET_LOCK 按名称释放；业务代码应把获取与释放放在同一会话边界内
SELECT GET_LOCK('billing:prod:daily_close', 5);
SELECT RELEASE_LOCK('billing:prod:daily_close');

两套接口都要求名称非空且最长 64 个字符，锁名按二进制字符串比较，所以大小写会影响是否相同。锁的生命周期是会话级：显式释放，或者会话正常/异常终止时释放；事务 COMMIT 与 ROLLBACK 都不会代替释放动作。

三、用一个选择表固定命名和接口边界

如果你要表达“同一资源允许多个读者，但写入必须独占”，锁定服务的模式更贴近需求。如果只是给定时任务、单实例初始化或某个轻量互斥操作取一个全局名字，GET_LOCK() 足够，但要把应用、环境和资源放入名称，减少跨团队碰撞。

四、排查命名冲突时看哪里

两者都基于 MySQL 的元数据锁框架，但 Performance Schema 中的对象类型不同。锁定服务使用 OBJECT_TYPE = 'LOCKING SERVICE'，其 namespace、name 和模式分别能映射到对象字段；GET_LOCK() 则显示为 USER LEVEL LOCK。

-- 只查询两类应用锁，避免把 GET_LOCK() 混在一起判断
SELECT OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS
FROM performance_schema.metadata_locks
WHERE OBJECT_TYPE IN ('LOCKING SERVICE', 'USER LEVEL LOCK');

排查时先确认三件事：调用方是否使用了同一个会话池连接、名称是否超过 64 个字符或大小写不一致、释放路径是否覆盖超时和异常分支。不要把“事务已经回滚”当作释放证据，也不要只看业务日志里的短名称；完整字符串或 namespace 才能解释真正的竞争关系。

常见问题

锁定服务的 namespace 能不能理解成数据库名？

不能直接等同。它是锁标识的一部分，可以按应用或模块设计；文档中会把它映射到监控字段，但它不是表或数据库对象本身。

GET_LOCK() 能模拟命名空间吗？

可以用 app:env:resource 这类字符串前缀模拟隔离，但那是应用约定，不是 GET_LOCK() 提供的独立 namespace 维度。

为什么 COMMIT 后锁还在？

这两类锁都属于会话级应用锁，事务提交和回滚不会释放；应显式调用对应释放函数，或确保连接结束。

总结

判断命名粒度时只记住一句话：锁定服务的键是 (namespace, name)，GET_LOCK() 的键是完整字符串。前者进一步提供读写锁和按命名空间释放，后者以单一排他锁换取更简单的调用方式。把这条边界写进连接封装和排查手册，后续的锁冲突会更容易定位。