select ... for update不能直接当分布式锁用，因其仅事务内可见、跨连接不可见，无法实现全局排他；必须配合唯一索引与显式事务，且仅适用于单实例内固定主键资源的轻量协调。
SELECT ... FOR UPDATE 为什么不能直接当分布式锁用
它只在当前事务内生效，事务一提交锁就释放，跨连接、跨服务完全不可见。两个服务各自开事务执行 SELECT ... FOR UPDATE，只要不操作同一行（或没走索引导致锁表），就互不影响——根本达不到“全局排他”效果。
常见错误现象：多个实例同时查到“资源可用”，都开始执行初始化逻辑，结果缓存被覆盖、通知发了多遍、库存扣超。
- 必须基于唯一索引（如主键、唯一键）才能锁住单行；否则可能升级为表锁，拖垮整个库
- 事务未提交前，其他事务对同一行的
SELECT ... FOR UPDATE会阻塞，但对其他行或全表查询不受影响 - 若业务逻辑中混用
SELECT ... FOR UPDATE和普通SELECT，后者读到的是快照（RR隔离级别下），可能看到过期数据
怎么用 SELECT ... FOR UPDATE 做轻量级排他协调
适用场景：单 MySQL 实例内，多个应用进程/线程争抢一个**已知主键 ID 的固定资源**，比如“刷新订单ID=12345的状态”“重试支付流水号=pay_789”。这时它比 GET_LOCK() 更可靠，因为锁状态随事务生命周期可控。
关键操作顺序不能错：
- 先
BEGIN开启事务 - 再
SELECT * FROM orders WHERE id = 12345 FOR UPDATE—— 必须命中索引，且 WHERE 条件能唯一定位一行 - 检查返回结果是否符合预期（比如 status != 'success'），不符合则
ROLLBACK并退出 - 执行业务逻辑（更新、调用外部服务等）
- 最后
COMMIT或ROLLBACK，锁自动释放
注意：FOR UPDATE 不支持超时等待，等待时间由 innodb_lock_wait_timeout 控制（默认 50 秒），超时抛出 Lock wait timeout exceeded 错误，需捕获并重试。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
为什么 INSERT + 唯一索引才是生产级分布式锁的主流方案
SELECT ... FOR UPDATE 天然无法解决“锁不存在时创建”的原子性问题——你得先查，再判断，再插，中间有竞态窗口。而 INSERT INTO distributed_lock (lock_key, expire_time) VALUES ('res:1001', NOW() + INTERVAL 10 SECOND) 是一条原子语句：成功即获锁，失败（1062 Duplicate entry）说明已被占用。
这个方案真正解决了三个硬伤：
- 锁带 TTL：靠
expire_time字段，后续用定时任务或乐观更新清理过期锁 - 跨实例可见：所有节点查同一张表，主从延迟不影响锁判断逻辑（只要读主库或强一致性从库）
- 连接无关：锁存在表里，不依赖连接生命周期，不怕连接池复用或崩溃失联
务必建唯一索引：UNIQUE KEY uk_lock_key (lock_key)，否则并发插入会绕过冲突检测。
容易被忽略的实战细节
很多人抄了 INSERT 方案，却在线上翻车，问题常出在三处：
- 没设
innodb_row_lock_wait_time_ms监控，锁冲突时只看到慢查询，找不到根因 - 释放锁用
DELETE FROM distributed_lock WHERE lock_key = ? AND expire_time > NOW()，但没加limit 1，万一误删其他锁就连锁崩塌 - 锁名含变量时没做标准化处理，比如
"order:" + orderId遇到空 orderId 变成"order:"，大量请求挤在同一个锁 key 上
真正的难点不在语法，而在锁生命周期管理：谁负责续期？超时后如何安全降级？失败时要不要退避？这些没法靠一条 SQL 解决。
