MySQL中实现乐观锁最直接方式是在UPDATE语句中用WHERE校验版本号，依赖SQL原子性而非数据库锁；SELECT+UPDATE两步法因存在时间窗口而不可靠，必须通过ROW_COUNT()判断影响行数是否为1来确认更新成功，版本号字段需设为NOT NULL DEFAULT 0，重试逻辑须由应用层闭环处理。
UPDATE 语句里加 WHERE 条件校验版本号，是 MySQL 中实现乐观锁最直接、最可控的方式。它不依赖数据库锁机制，而是靠应用层逻辑和 SQL 原子性来保证并发安全。
为什么不能只靠 SELECT + UPDATE 两步走？
很多人误以为“先查再改”就能实现乐观锁，但这是错的——SELECT 和 UPDATE 是两个独立语句，中间存在时间窗口。哪怕隔离级别是 READ COMMITTED 或 REPEATABLE READ，MVCC 只保证读一致性，不阻止其他事务在你 SELECT 后、UPDATE 前修改数据。
真正起作用的是 UPDATE 语句自身的原子性：WHERE 条件必须同时满足“主键匹配”和“版本号未变”，否则 UPDATE 影响行为 0 行。
-
UPDATE product SET stock = stock - 1, version = version + 1 WHERE id = 1 AND version = 5;—— 这一行必须完整执行 - 如果另一事务已将
version改为 6，这条语句就什么也不做，ROW_COUNT()返回 0 - 不能拆成
SELECT ... WHERE id = 1→ 应用层计算 →UPDATE ... SET version = 6 WHERE id = 1 AND version = 5，因为中间可能被抢
ROW_COUNT() 是判断是否更新成功的唯一可靠依据
MySQL 的 ROW_COUNT() 函数返回上一条 UPDATE（或 INSERT/DELETE）实际影响的行数。乐观锁成败，就看它是不是 1。
- 执行
UPDATE后立刻调用SELECT ROW_COUNT();（或用客户端驱动的affectedRows属性） - 返回 1：更新成功，版本已递增，业务可继续
- 返回 0：说明
WHERE条件不成立——要么数据已被改，要么根本不存在该id - 不要依赖
UPDATE是否报错：它不会报错，只是“静默失败”
版本号字段必须是 INT，且初始值不能为 NULL
版本号字段设计不当，会导致条件永远不匹配，所有更新都失败。
- 建表时明确设默认值：
version INT NOT NULL DEFAULT 0，避免NULL参与=比较（NULL = 0结果为UNKNOWN，不成立） - 不要用
TIMESTAMP或DATETIME做乐观锁主校验字段：精度问题（如 MySQL 默认秒级）、时区差异、手动更新风险高 - 如果已有历史数据，批量初始化版本号：
UPDATE table_name SET version = 0 WHERE version IS NULL; - 避免用
auto_increment或触发器自增version：它必须由应用控制，否则失去“比较-更新”原子语义
重试逻辑必须由应用层闭环处理
MySQL 不提供“自动重试”能力。当 ROW_COUNT() == 0 时，你要决定是抛异常、返回错误，还是主动重试。
- 简单场景（如下单扣库存）可立即重试 1–2 次：
SELECT当前值 → 计算新值 →UPDATE带版本校验 - 注意重试间隔：无延迟连续重试可能加剧冲突，加几毫秒随机抖动更稳妥
- 业务关键路径（如支付）建议记录冲突日志，而非无限重试，防止雪崩
- 不要在存储过程中封装“重试循环”：MySQL 存储过程无法感知外部事务状态，且难以调试
版本号不是万能解药。它把锁冲突从数据库层转移到了应用层，也把“失败后怎么办”的责任完全交给了你。最容易被忽略的，其实是重试时没重新 SELECT 最新数据——拿着过期的 version 和 stock 值反复提交，只会让失败持续发生。
