必须检查UPDATE的ROW_COUNT()：0表示版本冲突（业务失败），1表示成功，负数或异常才是系统错误；version须为INT/BIGINT并建(id,version)组合索引，DEFAULT 0；MyBatis-Plus需配OptimisticLockerInnerInterceptor且仅对updateById等生效。
UPDATE WHERE version = ? 必须检查 ROW_COUNT()
影响行数为 0 就代表冲突，不是系统异常，而是业务预期中的失败。不检查 ROW_COUNT() 是线上超卖、金额错乱最常见源头。
MySQL 的 UPDATE 语句本身不会抛错，它只按条件匹配并更新——条件不成立时安静地返回 0 行影响。应用层必须立刻调用等价于 ROW_COUNT() 的 API（JDBC 的 getUpdateCount()、MyBatis 的 update() 返回值、PDO 的 rowCount()）来判断结果。
- 返回 1：更新成功，可继续后续逻辑
- 返回 0：版本已变，数据被他人抢先修改，需重试或返回
409 Conflict - 返回负数或异常：才是数据库连接、语法等真正错误
version 字段必须是 INT/BIGINT，且建组合索引 (id, version)
用 VARCHAR 存 “v1”、“v2” 或用 TIMESTAMP 记时间，都会引入精度漂移、时钟不同步、字符串比较慢等问题，导致误判或性能下降。
整型版本号天然支持原子自增、无歧义比较，且 MySQL 对整型索引优化极好。单列 INDEX(version) 效果差——因为实际查询永远带 id 条件，WHERE id = ? AND version = ? 走不到单列索引的高效路径。
- 正确建法：
ALTER TABLE product ADD INDEX idx_id_version (id, version); - 不要用
DEFAULT NULL，必须设DEFAULT 0，否则首次插入时 MyBatis-Plus 等框架可能跳过 version 初始化 - 避免在
WHERE中混用函数，比如WHERE id = ? AND version >= ?，会破坏索引有效性
MyBatis-Plus @Version 不是开箱即用，得手动对齐三处
@Version 注解只是标记字段，真正起作用的是 OptimisticLockerInnerInterceptor 插件，但它只拦截特定方法，且对字段类型和默认值极其敏感。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 实体类中字段类型必须是
Integer或Long，不能是int（非空基本类型会导致默认值 0 被覆盖） - 数据库字段必须为
INT DEFAULT 0，不能是INT NULL或INT DEFAULT 1 - 插件仅生效于
updateById()和带Wrapper的update()；对execute()原生 SQL、updateBatchById()、lambdaUpdate().set()等写法完全无效
高并发下 version 自增可能触发间隙锁争抢
当多个事务几乎同时执行 UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?，即使最终只有一个成功，MySQL 在执行过程中仍会对满足 WHERE 条件的索引记录加间隙锁（gap lock），尤其在 RR 隔离级别下。这可能导致看似“乐观”的操作，实际引发阻塞甚至死锁。
这不是 bug，是 InnoDB 实现 MVCC 和唯一性约束的副产品。真正的缓解点不在 SQL 写法，而在业务设计：
- 把长事务拆短，减少持有锁的时间窗口
- 对热点行（如商品 ID=1）做分桶处理（例如库存拆成 10 个子项，扣减时随机选一个）
- 避免在乐观锁更新后立即读取新值再更新——这会放大锁竞争
版本号机制本身轻量，但它的“轻量”建立在低冲突假设上；一旦冲突频发，重试成本和锁竞争会迅速反噬性能。别只盯着 SQL 怎么写，先想清楚这行数据到底是不是真适合用乐观锁。
