MySQL 锁定服务怎样按命名空间取得读锁

MySQL 8.4 的锁定服务可以通过 service_get_read_locks() 在指定命名空间里取得一个或多个共享读锁。调用时把命名空间放在第一个参数，把锁名放在中间，把等待秒数放在最后；读锁允许其他会话继续取得同一标识的读锁，但会和同一标识上的写锁互斥。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/locking-service.html。本文讨论 MySQL 8.4 的 SQL 锁定服务函数，不把事务提交、回滚和锁释放混为一谈。

先分清命名空间、锁名和读锁

锁定服务用“命名空间 + 锁名”组成一个锁标识。例如 (orders, order:1001) 与 (reports, order:1001) 的锁名相同，但属于不同命名空间，彼此不会因为名字相同而冲突。命名空间和锁名都不能是 NULL 或空字符串，长度最多 64 个字符，并按二进制字符串比较，因此大小写不同也会被视为不同名称。

这套接口适合把“某个资源正在被某类业务读取”的协作约定放在 MySQL 会话层。它不是表行锁，也不会自动替应用检查权限；同名锁能否取得，只由命名空间、锁名和锁模式的组合决定。

用 SQL 函数取得命名空间读锁

SQL 接口由可加载函数提供，首次使用前需要在目标实例安装对应函数。官方文档给出的插件库基名是 locking_service，实际后缀随平台变化。下面的安装语句只应由管理连接在明确的测试或生产变更窗口执行。

-- 管理连接：把锁定服务函数注册到当前 MySQL 实例。
CREATE FUNCTION service_get_read_locks RETURNS INT
  SONAME 'locking_service.so';
CREATE FUNCTION service_get_write_locks RETURNS INT
  SONAME 'locking_service.so';
CREATE FUNCTION service_release_locks RETURNS INT
  SONAME 'locking_service.so';

函数安装完成后，读锁调用格式是 service_get_read_locks(namespace, lock_name[, lock_name] ..., timeout)。一次调用可以包含多个锁名，最后一个整数是等待秒数，而不是要锁定的资源数量。

-- 业务连接：在 orders 命名空间中同时请求两个共享读锁，最多等待 5 秒。
SELECT service_get_read_locks('orders', 'order:1001', 'order:1002', 5);

-- timeout 为 0：只接受立即可用的读锁，不进入等待。
SELECT service_get_read_locks('orders', 'order:1003', 0);

返回非零值表示请求成功；如果锁名非法、超时或发生死锁，函数会产生错误。若另一会话持有同一锁标识的写锁，读锁请求会等待，直到写锁释放或达到 timeout。命名空间不同，即使锁名相同，也不会参加同一组冲突判断。

读锁共享，但多锁调用仍有边界

同一个会话可以重复取得相同标识的锁，其他会话只要没有该标识的写锁，就可以继续取得读锁。反过来，只要某个会话持有写锁，其他会话对同一 (namespace, lock_name) 不能再取得读锁或写锁。

一个调用里的多个锁具有原子性：全部取得才算成功，任意一个锁失败时本次调用不会留下这次调用取得的锁。但原子性不会跨越多次函数调用。不要把下面两次调用当作一个不可分割的资源集合：

-- 第一次调用只保证 lock_a 与 lock_b 这一组的原子性。
SELECT service_get_read_locks('orders', 'lock_a', 'lock_b', 3);

-- 第二次调用与上一次之间没有跨调用原子性。
SELECT service_get_read_locks('orders', 'lock_c', 3);

还要注意锁定服务的锁不是事务锁：事务提交或回滚不会释放它们。若把逐行结果中的每一行都传给一次锁函数，可能积累大量独立锁，且结果集顺序也不应被当成锁定顺序。工程上更适合按一次业务操作整理锁名，减少调用次数和 namespace 里的无关资源。

释放锁并从 Performance Schema 判断状态

释放时不需要逐个传入 lock_name，service_release_locks(namespace) 会释放当前会话在该命名空间中通过锁定服务取得的全部锁。因为它按命名空间成组处理，所以命名空间最好对应明确的业务生命周期，不要把互不相关的任务塞进同一个 namespace。

-- 业务连接：释放当前会话在 orders 命名空间中的全部锁。
SELECT service_release_locks('orders');

如果会话正常或异常终止，锁也会随会话隐式释放；不过连接池不应依赖异常断开来清理业务状态，借出和归还连接时仍要有明确的释放策略。锁定服务使用元数据锁框架，可以从 Performance Schema 查看命名空间、锁名、模式和状态：

-- 管理连接：开启元数据锁观测仪表。
UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES'
WHERE NAME = 'wait/lock/metadata/sql/mdl';

-- 只查看锁定服务对象，避免把 GET_LOCK() 的用户级锁混在一起。
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS
FROM performance_schema.metadata_locks
WHERE OBJECT_TYPE = 'LOCKING SERVICE';

结果里的 OBJECT_SCHEMA 是命名空间，OBJECT_NAME 是锁名，SHARED 表示读锁，EXCLUSIVE 表示写锁；GRANTED 表示已取得，PENDING 表示仍在等待。排查时先确认 namespace 是否一致，再看锁模式和持有会话，最后决定是延长等待、释放旧会话，还是改用更细的资源命名。

常见问题

命名空间不同，锁名相同会互相阻塞吗？

不会。锁标识由命名空间和锁名共同组成；只有两部分都相同，读写兼容判断才会落到同一个标识上。

读锁成功后提交事务会自动释放吗？

不会。锁定服务锁独立于事务提交与回滚，应显式调用 service_release_locks(namespace)，或者让会话结束触发隐式释放。

为什么一次请求多个锁失败后还要检查会话状态？

单次调用本身是原子的，但同一会话此前的调用可能已经持有其他锁；释放是按命名空间成组进行的，不能把“本次调用失败”理解成整个会话没有任何锁。

依据：MySQL 8.4 锁定服务官方说明，重点参考命名空间、读写模式、超时、死锁、释放规则和 Performance Schema 监控字段。示例用于说明调用边界，未把静态说明图当作实际运行结果。