在业务开发中，字段值的累加更新是非常常见的操作，比如用户消费后增加积分、商品被购买后累加销量、文章被阅读后更新阅读量等。这类操作如果处理不当，很容易出现数据错误或者性能瓶颈。
为什么不建议先查后改的累加方式
很多开发者实现字段累加时，会先执行查询语句获取字段当前值，在应用层计算累加后的结果，再执行更新语句写入数据库，示例逻辑如下：
// 先查询当前积分 String querySql = "SELECT points FROM user WHERE id = 1"; int currentPoints = executeQuery(querySql); // 计算累加后的积分 int newPoints = currentPoints + 100; // 更新积分 String updateSql = "UPDATE user SET points = " + newPoints + " WHERE id = 1"; executeUpdate(updateSql);
这种方式存在两个明显的问题：
- 数据一致性问题：如果两个请求同时查询到相同的当前值，计算后写入的结果会覆盖其中一个请求的更新，导致累加结果错误。
- 性能开销问题：需要两次数据库交互，增加了网络往返时间和数据库的处理压力，在高并发场景下会明显影响系统性能。
使用原子更新语句实现字段累加
SQL本身支持直接在更新语句中引用字段当前值进行计算，这种操作是原子性的，数据库会保证同一时间只有一个请求能执行该更新，避免并发冲突，同时只需要一次数据库交互。
基础累加更新语法
通用的累加更新语句格式如下，不同数据库语法基本一致：
UPDATE 表名 SET 字段名 = 字段名 + 累加值 WHERE 条件;
比如要给id为1的用户增加100积分，直接执行以下语句即可：
UPDATE user SET points = points + 100 WHERE id = 1;
带条件的累加更新
如果需要在累加时增加额外的判断条件，比如只有用户状态为正常时才允许累加积分，可以在WHERE子句中添加条件：
UPDATE user SET points = points + 100 WHERE id = 1 AND status = 'normal';
累加同时更新其他字段
如果需要在累加字段的同时更新其他字段，比如更新积分的同时更新最后修改时间，可以在SET子句中添加多个字段的更新逻辑：
UPDATE user SET points = points + 100, last_modify_time = NOW() WHERE id = 1;
原子更新对性能的优化作用
使用原子更新语句相比先查后改的方式，性能优化主要体现在以下几个方面：
- 减少数据库交互次数：从两次请求减少到一次，降低了网络延迟和数据库的连接开销。
- 避免行级锁持有时间过长：先查后改的方式需要先加共享锁查询，再升级为排他锁更新，锁持有时间更长；原子更新直接加排他锁执行更新，锁持有时间更短，能减少锁竞争。
- 降低应用层计算压力：累加计算由数据库层完成，减少了应用层的计算逻辑，尤其适合批量累加的场景。
不同数据库的特殊场景处理
MySQL的批量累加更新
如果需要给多个用户批量增加不同的积分，可以使用CASE表达式实现：
UPDATE user
SET points = CASE
WHEN id = 1 THEN points + 100
WHEN id = 2 THEN points + 200
WHEN id = 3 THEN points + 150
END
WHERE id IN (1,2,3);
PostgreSQL的RETURNING子句
如果需要更新后直接获取累加后的字段值，PostgreSQL支持RETURNING子句：
UPDATE user SET points = points + 100 WHERE id = 1 RETURNING points;
注意事项
- 累加值如果是变量，需要注意SQL注入问题，建议使用预编译语句传参，不要直接拼接SQL字符串。
- 如果字段可能为NULL，需要先处理NULL值，比如使用COALESCE函数：
SET points = COALESCE(points, 0) + 100，避免NULL参与计算导致更新结果为NULL。 - 累加操作如果涉及大量数据，建议分批次执行，避免单次更新锁住过多行影响其他业务操作。