mysql分布式锁有三种主流方案：get_lock()最快但限同连接；唯一索引表最通用需自管过期；select...for update贴近事务但易锁表。无银弹，需按场景选择。
MySQL 实现分布式锁不是“能不能”的问题，而是“选哪条路、怎么避坑”的问题。直接用 GET_LOCK() 最快但不跨会话；用唯一索引表最通用但得自己管过期；用 SELECT ... FOR UPDATE 最贴近事务语义但极易锁表。没有银弹，只有匹配场景的解法。
用 GET_LOCK() 快速加锁，但必须同连接复用
这是 MySQL 内置的命名锁函数，调用简单、带超时、崩溃自动释放，适合短时、单次操作。
-
GET_LOCK('order:1001', 5)返回1表示获锁成功，0表示超时失败，NULL表示参数非法 - 释放必须用同一个数据库连接执行
RELEASE_LOCK('order:1001')，换连接或连接断开后锁自动释放 - 不能在不同连接间传递锁状态——Spring Boot 中用 MyBatis 的
@Mapper默认每次执行都可能走新连接，容易误判为“已释放”而重复加锁 - 锁名长度限制 64 字节，且只支持 ASCII 字符；中文或长业务标识需哈希截断（如
SUBSTR(SHA2('库存:商品A', 256), 1, 64)）
基于唯一索引表实现可持久、可过期的锁
这是生产环境最常落地的方案，核心是靠 INSERT 原子性 + 唯一约束互斥，配合 expire_time 防死锁。
- 建表时必须有
UNIQUE KEY uk_lock_key (lock_key)，否则插入冲突无法触发互斥 - 获取锁用
INSERT INTO distributed_lock (lock_key, expire_time) VALUES ('stock:20', DATE_ADD(NOW(), INTERVAL 10 SECOND))，成功即获锁；失败抛ER_DUP_ENTRY异常（错误码 1062） - 释放锁必须带条件删除：
DELETE FROM distributed_lock WHERE lock_key = 'stock:20' AND expire_time > NOW()，避免删掉别人续期后的锁 - 没人主动释放？靠定时任务或应用启动时扫描
expire_time 的记录清理，但注意：清理操作本身也要加锁防并发误删
用 SELECT ... FOR UPDATE 绑定业务事务，但索引是生死线
当你希望“加锁 → 查数据 → 更新 → 提交”全在一个事务里原子完成时，这个方案最自然，但它对索引极度敏感。
- WHERE 条件字段（如
lock_key）**必须有索引**，否则 MySQL 会升级为表锁，整个distributed_lock表瞬间串行化 - 推荐主键或唯一索引查询：
SELECT * FROM distributed_lock WHERE lock_key = 'order:1001' FOR UPDATE，能命中索引才锁单行 - 不能用
SELECT ... FOR UPDATE查询不存在的lock_key——InnoDB 会在间隙上加锁（Next-Key Lock），阻塞其他插入，引发隐式锁竞争 - 事务持续时间越长，锁持有越久，建议业务逻辑控制在 2 秒内，超时由应用层主动 rollback，避免长事务拖垮连接池
锁续期和重入性是业务层责任，MySQL 不管
MySQL 所有方案都不原生支持“同一个客户端多次获取同一把锁”或“延长锁有效期”，这些必须由应用代码兜底。
- 重入判断：在插入/更新时写入客户端唯一标识（如
request_id），释放前先SELECT校验是否为自己所持 - 续期操作本质是
UPDATE distributed_lock SET expire_time = DATE_ADD(NOW(), INTERVAL 10 SECOND) WHERE lock_key = ? AND request_id = ?，需检查影响行数是否为 1 - 所有涉及时间的比较（如
expire_time > NOW()）务必用 MySQL 服务端时间，禁止用应用服务器时间，否则时钟漂移会导致锁提前失效或永久不释放
