MySQL锁机制本身不直接实现幂等性，它只是保障并发安全的工具；真正起幂等作用的是唯一标识、唯一索引约束、状态机校验与事务内SELECT FOR UPDATE（需唯一索引+显式事务）协同配合，缺一不可。
MySQL 锁机制本身不直接“实现幂等性”，它只是保障并发安全的工具；真正起幂等作用的是你如何用锁配合业务逻辑、状态判断和唯一约束来拦截重复操作。盲目加 FOR UPDATE 或乱用 SELECT ... LOCK IN SHARE MODE 不仅无效，还可能引发死锁或性能雪崩。
为什么不能只靠 SELECT ... FOR UPDATE 做幂等校验
很多人以为“查完立刻加行锁，后面就安全了”，但这是典型误解：
- 如果
SELECT ... FOR UPDATE查不到记录（比如首次插入前），那这把锁根本没生效——InnoDB 只对已存在的索引记录加锁，对空结果集不锁任何东西 - 即使查到了，锁住的也只是当前满足条件的行；如果业务逻辑里还有 INSERT 或 UPDATE 操作，且没在同一个事务里串起来，锁一提交就释放，中间窗口期照样被并发写穿
- 若 WHERE 条件没走索引（比如用了函数、隐式类型转换），
FOR UPDATE会升级为表锁或间隙锁，拖垮整个表的写性能
FOR UPDATE 必须搭配唯一索引 + 显式事务才能用于幂等
只有当你要“先查后改”，且该查的记录一定存在（或能通过唯一键预判存在性）时，FOR UPDATE 才有意义。典型场景是状态流转类更新，例如支付单状态从 'created' → 'paid'：
START TRANSACTION; SELECT status FROM orders WHERE order_id = 'ORD123' AND status = 'created' FOR UPDATE; -- 如果查到一行，说明可更新；查不到则直接返回“已处理” UPDATE orders SET status = 'paid', updated_at = NOW() WHERE order_id = 'ORD123' AND status = 'created'; COMMIT;
- 必须确保
order_id是主键或有唯一索引，否则FOR UPDATE可能锁住非目标行甚至整张表 -
SELECT和UPDATE必须在同一个事务中，且SELECT的 WHERE 条件要和UPDATE完全一致（包括状态判断），否则锁住的行和实际更新的行可能不匹配 - 应用层必须检查
UPDATE影响行数是否为 1；为 0 表示已被其他线程抢先更新，此时应拒绝本次请求，而非重试或忽略
INSERT 场景下，FOR UPDATE 几乎无用，该用唯一索引
想防重复下单？别想着先 SELECT ... FOR UPDATE 再 INSERT——这中间永远有竞态窗口。正确做法是直接 INSERT ... ON DUPLICATE KEY UPDATE 或依赖唯一索引报错：
INSERT INTO orders (order_id, user_id, amount)
VALUES ('ORD123', 1001, 99.9)
ON DUPLICATE KEY UPDATE status = status;- 前提是
order_id字段建了UNIQUE KEY；否则ON DUPLICATE KEY不触发 - 如果业务需要区分“插入成功”和“已存在”，就捕获 MySQL 错误码
1062（Duplicate entry），而不是靠锁去规避 - 试图用
SELECT ... FOR UPDATE查是否存在再决定是否插入，本质上把数据库当缓存用，违背了 ACID 原则，且高并发下必然失败
最容易被忽略的点：锁粒度与事务边界
很多团队加了 FOR UPDATE 却仍出问题，核心原因是锁没锁住真正要保护的资源：
- 锁的是业务主键（如
order_id），不是用户 ID 或时间范围这类模糊条件 - 事务开始太晚（比如在 HTTP handler 里才
BEGIN），导致前置校验（如 token 验证、参数解析）耗时过长，锁持有时间被拉长 - 没设
innodb_lock_wait_timeout，死锁或长等待时不抛异常，而是静默卡住，最终超时断连，前端重试又来一轮 - 忘记在应用层统一处理锁冲突异常（MySQL 错误码
1205是死锁，1213是锁等待超时），而是让异常穿透到上层，导致部分逻辑执行了、部分没执行
真正可靠的幂等，从来不是靠某一个 SQL 技巧，而是由唯一标识（如业务单号）、存储层约束（唯一索引）、应用层状态机（如 status 字段的合法跳转）三层共同兜底。锁只是其中一环，且只在“查-改强依赖”的窄场景里才值得用。
