版本号字段是应用层实现乐观锁的关键手段，用于防止并发更新导致的“丢失更新”问题；通过WHERE version = ?校验确保仅更新未被修改的记录，并检查影响行数判断是否需重试。

UPDATE时为什么需要版本号字段

版本号（如 version 或 updated_at）不是SQL语法要求，而是应用层实现乐观锁的关键手段。它解决的是并发更新冲突问题：当两个事务同时读取同一行、各自修改后提交，后提交者会覆盖前者的变更——这种“丢失更新”在订单状态、库存扣减等场景中极其危险。单纯靠数据库事务无法防止，必须靠业务层校验。

如何用WHERE version = ? 实现安全更新

核心是把版本号作为UPDATE的WHERE条件一部分，确保只更新“当前仍是这个版本”的记录。一旦其他事务已抢先更新，该行的version已变，本次UPDATE将影响0行。

• 建表时加version字段：ALTER TABLE orders ADD COLUMN version INT DEFAULT 0;
• 读取时带出版本：SELECT id, status, version FROM orders WHERE id = 123;
• 更新时校验并递增：UPDATE orders SET status = 'shipped', version = version + 1 WHERE id = 123 AND version = 5;
• 执行后必须检查影响行数：MySQL用ROW_COUNT()，PostgreSQL用result.rowcount，SQL Server用@@ROWCOUNT；返回0说明已被别人改过，需重试或报错

常见错误：版本号没校验或类型不匹配

很多团队加了version字段却没在WHERE里用，等于没锁。更隐蔽的问题是类型不一致：

• version定义为TIMESTAMP但WHERE里传字符串'2026-08-05 09:30:00'，可能因时区或精度导致匹配失败
• 用updated_at替代version，但多个字段同时更新时updated_at被自动刷新，导致WHERE条件永远不成立
• ORM自动生成SQL时忽略version字段，比如Django默认不注入乐观锁逻辑，需手动在filter()中显式添加version=xxx

批量更新和高并发下的注意事项

版本号方案对单行更新有效，但不适合大批量操作（如“把所有待发货订单设为已发货”），因为每行版本不同，无法统一WHERE条件。此时应考虑：

• 改用悲观锁：SELECT ... FOR UPDATE锁定目标行再更新，但会阻塞其他事务
• 引入分布式锁（如Redis锁）控制批量任务入口
• 接受最终一致性：用消息队列异步更新，失败重试+幂等设计

真正容易被忽略的是：版本号本身不能防住“先读后写”以外的逻辑错误，比如WHERE条件写错、SET字段拼错。它只保并发安全，不保语义正确——所以仍要搭配事务、预检SELECT和影响行数校验。