优先用带条件的UPDATE+ROW_COUNT()检查配合version字段实现乐观锁；分段更新仅适用于批量修正等少数场景，不能替代并发控制逻辑。
直接结论：优先用带条件的 UPDATE + ROW_COUNT() 检查，配合 version 字段实现乐观锁；分段更新只在极少数场景（如批量修正）中作为兜底手段，不能替代并发控制逻辑。
为什么不能靠 UPDATE ... WHERE id = ? 自动防覆盖
单靠主键 WHERE 只能保证“行存在”，不保证“状态未变”。比如两个事务同时读到 status = 'pending'，又都执行 UPDATE orders SET status = 'processing' WHERE id = 123，后提交的会直接覆盖前一个——MySQL 不报错，ROW_COUNT() 还是 1。
- 必须把业务预期状态放进
WHERE，例如WHERE id = 123 AND status = 'pending' - 执行后立刻检查
ROW_COUNT()：为 0 表示已被改过，不是异常，是正常并发信号 - 非索引字段（如
WHERE name = 'alice'）会导致锁升级，可能锁表，务必确认字段有索引
version 字段怎么设才真正起作用
version 不是加了就安全，类型、递增方式、使用时机都影响效果。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
version必须是INT或BIGINT，不能用TIMESTAMP（时钟漂移、精度不足） - 每次更新必须写成
SET version = version + 1，不能写死值（如SET version = 5） - 应用层必须先
SELECT id, status, version FROM table WHERE id = ?，再拼WHERE id = ? AND version = ? - 如果更新失败（
ROW_COUNT() == 0），要重新SELECT最新数据，而不是直接重试旧 version 值
SELECT ... FOR UPDATE 什么情况下真该用
它不是“更安全的替代方案”，而是高代价的强一致性工具，用错反而放大问题。
- 只在事务内有效，且锁持续到
COMMIT或ROLLBACK，中间调远程 API 就等于锁住整行几十秒 - 必须走主键或唯一索引，
SELECT * FROM user WHERE email = ? FOR UPDATE若email无索引，实际锁全表 - 多个线程按不同顺序访问多行（如 A→B 和 B→A）极易死锁，日志里看到
Deadlock found when trying to get lock就是它 - READ COMMITTED 隔离级别下只锁匹配行；REPEATABLE READ 下还锁间隙（gap lock），范围更大
分段更新不是并发解法，只是降低冲突概率
把“更新一行”拆成“更新一批”（如 UPDATE ... WHERE id IN (1,2,3)），本质是减少竞争点数量，并未解决单行竞争。
- 适合后台批量修复、数据迁移等低实时性场景
- 对高频单行操作（如扣库存、抢订单）无效：冲突仍集中在热点 ID 上
- 若强行用分段绕过锁，可能引入新问题——比如误更新其他本不该动的行
- 真正需要的是业务层收敛：用消息队列串行化请求，或 Redis 原子计数器预占资源
version 字段和条件 WHERE 是最轻量也最可控的路径，但很多人漏掉最关键一步：应用层必须把 ROW_COUNT() == 0 当作正常分支处理，而不是忽略或当错误打日志。这点不落地，再好的数据库机制也白搭。
