MySQL GET_LOCK 怎样实现同一任务的单实例执行

如果同一个定时任务可能被多个 worker 同时拉起，可以让它们先争抢一个稳定的 MySQL 命名锁：拿到锁的会话继续执行，返回 0 的会话直接退出。关键点是，锁属于数据库连接，不属于事务；提交或回滚事务不会自动释放它。

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

在同一个 mysqld 实例内，使用同一个锁名调用 GET_LOCK()，返回 1 才代表当前会话取得执行权；返回 0 表示等待超时，返回 NULL 表示函数执行出错。

先把锁名设计成应用级标识

锁名是协作协议的一部分。建议使用应用或业务前缀，例如 billing.task.refresh，不要只写 refresh。这样可以减少不同应用误用同一个服务端命名空间的风险。MySQL 8.4 对锁名有 64 个字符的长度限制，因此锁名要稳定、短且能表达任务边界。

同一任务的所有执行器必须计算出相同的名字；如果把日期、随机数或 worker ID 拼进锁名，实际上就变成了不同的锁，无法实现单实例。

用 GET_LOCK 的返回值决定是否执行

最小判断动作是 SELECT GET_LOCK('锁名', 超时秒数)。超时参数是等待时间，传入负数表示无限等待；生产任务通常更适合有限等待，拿不到锁就记录原因并退出，避免 worker 永久占用。

-- 只让一个会话进入刷新任务，等待 3 秒仍拿不到就放弃
SELECT GET_LOCK('billing.task.refresh', 3) AS lock_result;

-- lock_result = 1：取得锁，可以执行任务
-- lock_result = 0：等待超时，没有取得锁，应安全退出
-- lock_result IS NULL：函数出错，应记录错误并中止本次任务

不要把“查询成功”当成“取得锁成功”。应用层应严格区分三种返回值：1 进入业务；0 走跳过路径；NULL 走错误路径。多个会话等待同一个锁时，获取顺序没有保证，因此不要把它当作公平队列。

把释放动作绑定到取得锁的同一连接

拿到命名锁后，执行任务和释放锁都必须使用同一个数据库会话。事务提交、回滚不会释放命名锁；常见的安全做法是在业务成功、业务失败和异常清理路径中都执行 RELEASE_LOCK()，同时确保连接池不会在释放前把连接交给另一个任务。

-- 释放当前连接取得的命名锁；DO 适合只关心释放动作的场景
DO RELEASE_LOCK('billing.task.refresh');

-- 返回 1：当前连接成功释放
-- 返回 0：锁不是当前连接建立的，不能强行释放
-- 返回 NULL：这个名字当前不存在或发生错误

如果进程或数据库连接异常终止，MySQL 会隐式释放该连接持有的命名锁。但这只能作为兜底，不能代替显式释放。连接池场景尤其要避免“拿锁用连接 A、释放时拿到连接 B”的写法。

长时间拿不到锁时怎样排查

先用 IS_USED_LOCK() 查询锁是否正在使用；如果返回连接标识，再结合实例会话信息定位持有者。需要观察锁名与持有关系时，可以在 Performance Schema 的 metadata_locks 表中寻找 OBJECT_TYPE = 'USER LEVEL LOCK' 的记录。

-- 先判断命名锁当前是否被占用
SELECT IS_USED_LOCK('billing.task.refresh') AS holder_connection_id;

-- 再查看用户级锁的名称和状态
SELECT OBJECT_NAME, LOCK_STATUS, OWNER_THREAD_ID
FROM performance_schema.metadata_locks
WHERE OBJECT_TYPE = 'USER LEVEL LOCK'
  AND OBJECT_NAME = 'billing.task.refresh';

排查时不要只看等待方的应用日志：持有锁的会话可能已经卡在外部接口、慢 SQL 或连接池归还流程中。先找到持有者，再决定终止任务、修复连接释放，或调整有限等待时间。

单实例执行的边界

GET_LOCK() 的锁范围是单个 mysqld。如果应用连接分别指向不同的 MySQL 实例，它们不会共享这把锁；因此多实例部署、读写分离或故障切换时，必须先确认所有执行器是否指向同一实例。

另外，官方文档提示命名锁函数不适合语句格式复制；在使用复制拓扑时，应结合当前 binlog 配置和部署方式评估。多个客户端还可能因为同时持有多个锁形成死锁，任务代码应保持一次调用只申请必要的锁，并避免不确定的多锁顺序。

快速检查清单

常见问题

GET_LOCK 返回 0 是报错吗？

不是函数错误，而是等待超时，说明当前会话没有取得这把锁。是否记录为业务告警，取决于任务是否允许跳过本轮。

提交事务后为什么别人仍然拿不到锁？

命名锁跟随连接，不跟随事务。事务提交后仍需执行 RELEASE_LOCK()，或者等待连接终止触发隐式释放。

能用 GET_LOCK 代替跨 MySQL 集群的分布式锁吗？

不能直接这样假设。它只在单个 mysqld 内协调同名锁，跨实例拓扑需要另外设计一致的协调位置和故障处理方式。