MySQL不提供分布式锁能力，其SELECT...FOR UPDATE和GET_LOCK()仅在单实例或同一连接内有效；跨实例、读写分离、分库分表等场景必须用Redis+Lua等方案实现全局互斥锁。
MySQL 本身不提供分布式锁能力
MySQL 的 SELECT ... FOR UPDATE 或 GET_LOCK() 只在单实例、同一连接会话或同一主库范围内有效。一旦涉及多应用实例、读写分离、分库分表或跨机房部署，这些机制就无法保证全局互斥——它们不是分布式锁，只是本地行锁或会话级命名锁。
什么时候必须自己加分布式锁
当业务逻辑要求「绝对全局唯一性」且操作跨越多个 MySQL 实例或服务进程时，比如：
- 库存扣减在多个微服务（如订单服务、营销服务）中并发调用
- 使用 MySQL + Redis 双写场景，需防止缓存与 DB 不一致的竞态
- 定时任务被多个节点（K8s Pod / 多台机器）同时触发，且依赖 MySQL 中某个状态字段做判断
此时仅靠 UPDATE ... WHERE stock > 0 不够：它能防超卖，但无法阻止两个请求同时读到库存=1、各自扣减后写入0（这是乐观锁适用场景），而分布式锁是用来串行化“检查+扣减+发消息+更新缓存”这一整段非原子逻辑的。
推荐方案：Redis + Lua 实现可重入、带自动续期的锁
比 ZooKeeper 更轻量，比数据库轮询更高效。关键点：
- 锁 key 必须包含业务标识（如
lock:order:create:uid_123），避免不同用户相互阻塞 - 使用
SET key value NX PX 30000原子设值，value 是唯一随机字符串（防止误删他人锁） - 释放锁必须用 Lua 脚本校验 value 再
DEL，否则可能删错 - 长任务需另起线程定期调用
GETSET或PEXPIRE续期，避免锁过期后其他节点介入
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
MySQL 自带 GET_LOCK() 的真实适用边界
它只适合单机、短时、低频、非核心路径的互斥，例如：
- 临时迁移脚本防止重复执行
- 存储过程中协调两个事务分支（仍在同一连接内）
不能用于 Web 应用并发控制：HTTP 请求生命周期远超锁默认超时（默认 31536000 秒但实际受 wait_timeout 影响），且连接池会让锁在连接归还后自动释放，导致不可预测的失效。另外，GET_LOCK() 在 MySQL 8.0.30+ 已标记为 deprecated，未来可能移除。
真正难的不是选哪种锁，而是识别出哪段逻辑「表面看是数据库操作，实则需要跨系统协调」——这种地方最容易漏掉分布式锁，等线上出现数据错乱才去查 binlog 和日志对账。
