直接用update配合算术运算符批量加减数值字段，需注意where条件防误改、null值用coalesce处理、避免溢出，并考虑数据库差异与大表锁风险。
UPDATE语句直接更新数值字段
想给数值字段批量加减固定值，最直接的方式就是用 UPDATE 配合算术运算符。不需要查出来再写回，更不推荐用程序循环处理——既慢又容易出错。
常见错误是漏写 WHERE 条件，导致整张表数据被误改。务必先确认条件是否精确匹配目标行，必要时先用 SELECT 验证：
SELECT id, amount FROM orders WHERE status = 'pending';
确认无误后再执行更新：
UPDATE orders SET amount = amount + 100 WHERE status = 'pending';
-
amount = amount + 100是标准写法，不是amount += 100（SQL 不支持复合赋值） - 加减操作会自动保留原始数据类型，但要注意溢出：比如
TINYINT字段加 200 可能变成负数或报错 - 如果字段允许
NULL，NULL + 100结果仍是NULL，不是 100 —— 需要显式处理：COALESCE(amount, 0) + 100
处理 NULL 值时的典型陷阱
很多业务场景里数值字段存在 NULL，而开发者常默认它等于 0。但 SQL 中任何数与 NULL 运算结果都是 NULL，这会导致“看起来没更新成功”。
比如执行 UPDATE user SET balance = balance - 50 WHERE id IN (1,2,3);，若其中某条记录 balance 是 NULL，那它的新值还是 NULL，不是 -50。
- 安全做法是用
COALESCE：SET balance = COALESCE(balance, 0) - 50 - 如果想跳过
NULL行，加条件限制：WHERE balance IS NOT NULL AND id IN (1,2,3) - 注意
COALESCE的第一个参数必须是非空表达式，否则仍可能返回NULL
MySQL / PostgreSQL / SQLite 的细微差异
基本语法一致，但几个关键点会影响实际效果：
- MySQL 支持
UPDATE ... SET col = col + 1 ORDER BY id LIMIT 10，可控制更新顺序和数量；PostgreSQL 和 SQLite 不支持LIMIT在UPDATE中（PostgreSQL 需用 CTE 模拟） - PostgreSQL 对类型更严格：
integer + numeric会隐式转为numeric，但 MySQL 可能截断小数 - SQLite 的
UPDATE不支持子查询直接出现在SET右侧（如SET x = (SELECT y FROM t2 WHERE t2.id = t1.id)在某些旧版本会失败）
大表更新时的性能与锁风险
千万级表执行 UPDATE 加减操作，容易触发长时间行锁甚至表锁，影响线上读写。
- 避免全表无条件更新，哪怕只是
SET num = num + 1—— 它依然要扫描并锁定所有行 - 分批更新更稳妥：用主键范围切片，例如
WHERE id BETWEEN 10000 AND 20000，每次更新 1 万行 - 注意事务日志增长：MySQL 的
innodb_log_file_size或 PostgreSQL 的 WAL 可能因大批量更新撑满磁盘 - 某些数据库（如 MySQL 5.7+）在
UPDATE中使用函数（如ROUND(num + 0.5)）可能使索引失效，导致全表扫描
真正麻烦的不是语法，而是没意识到加减操作背后牵扯的锁、日志、类型转换和 NULL 处理。跑之前多看一眼执行计划，比修 bug 省三天。
