能，但非常脆弱；MySQL行锁本质是事务级行锁，非为分布式协调设计，多节点、网络延迟、异常中断下易失效，且无租约续期、崩溃自动释放不可控。
MySQL行锁能当分布式锁用吗？能，但非常脆弱
直接说结论：SELECT ... FOR UPDATE 在单库单表场景下可以模拟分布式锁，但一旦涉及多节点、网络延迟、事务异常中断或死锁，它就不再是“锁”，而是“定时炸弹”。它的本质是事务级行锁，不是为跨服务协调设计的。
常见错误现象：Lock wait timeout exceeded、应用卡住不报错、两个服务同时写入同一资源、事务意外 rollback 后锁自动释放却没通知客户端。
- 必须在显式事务中使用，
BEGIN→SELECT ... FOR UPDATE→ 业务逻辑 →COMMIT/ROLLBACK - 锁定目标必须有唯一索引（最好是主键），否则会升级为表锁——
SELECT * FROM order WHERE user_id = 123 FOR UPDATE若user_id无索引，整张表被锁 - 超时由
innodb_lock_wait_timeout控制（默认 50 秒），但这个值对分布式场景太长，且无法 per-query 覆盖 - 不支持租约续期、锁持有者崩溃后无法自动释放（除非事务超时回滚，但时间不可控）
怎么避免 SELECT FOR UPDATE 触发死锁？关键在顺序和范围
死锁不是小概率事件，而是可复现的设计缺陷。MySQL 的死锁检测会选一个事务回滚，但你无法预测谁被干掉——可能正是那个刚扣完库存、还没发消息的服务。
典型触发场景：两个服务按不同顺序更新两行；或一个用等值条件、另一个用范围条件扫描同一索引；或高并发下 INSERT ... ON DUPLICATE KEY UPDATE 和 SELECT ... FOR UPDATE 交叉执行。
- 所有服务必须按**完全相同的顺序**获取锁，例如统一按
id升序排列后再加锁：SELECT * FROM stock WHERE id IN (101, 205) ORDER BY id FOR UPDATE - 避免
SELECT ... FOR UPDATE带OR、函数、隐式类型转换——这些会让优化器跳过索引，扩大锁范围 - 不要在一个事务里先
SELECT ... FOR UPDATE再INSERT新行（尤其自增主键），InnoDB 可能在间隙（gap）上加锁，引发意料外冲突 - 用
SHOW ENGINE INNODB STATUS查看最近死锁详情，重点看*** (1) WAITING FOR THIS LOCK TO BE GRANTED:和*** (2) HOLDS THE LOCK(S):部分
如何给行锁加可控超时？别碰 innodb_lock_wait_timeout
改全局变量 innodb_lock_wait_timeout 是危险操作：影响所有事务，且无法区分“加锁超时”和“业务处理超时”。真正该控制的是「尝试获取锁」这一步的等待时间。
MySQL 本身不支持 SELECT ... FOR UPDATE WAIT N（8.0.1 以后才支持 WAIT 5，但旧版本仍占主流）。所以得靠应用层兜底。
- 用
SET innodb_lock_wait_timeout = 3在事务开头临时设低值，但需确保后续语句不依赖长锁等待 - 更稳妥做法：在应用里做最多 N 次重试，每次执行前
SELECT ... FOR UPDATE NOWAIT（MySQL 8.0.1+）或捕获Lock wait timeout exceeded错误码 1205/1213 - 配合 Redis 做锁状态缓存：加锁前先
SET lock:order_123 "svc-a" NX EX 10，成功再进 MySQL 事务；失败则直接退出——这不是替代，而是快速拒绝 - 注意：
NOWAIT报错是ERROR 3572 (HY000): Statement aborted because lock(s) could not be acquired immediately，不是 1205
为什么不用 ZooKeeper 或 etcd？因为行锁根本不是分布式锁协议
行锁没有租约（lease）、没有心跳续期、没有观察者机制、不保证 FIFO 获取顺序、崩溃后恢复不可控。它只是 ACID 里的一个实现细节，被强行拔高到分布式协调层，等于拿螺丝刀当手术刀。
如果你的系统已经重度依赖 MySQL，又暂时没法引入新组件，那至少做到：只锁最小粒度单行、事务极短（Innodb_row_lock_waits 和 Innodb_row_lock_time_avg 这两个指标。
真正的分布式锁服务需要解决的问题，行锁一个都没覆盖：节点失联判断、时钟漂移容忍、脑裂防护、锁迁移……这些不是调个参数能搞定的。
