UPDATE语句中直接用SET col = col + N不完全安全，存在NULL值导致更新失效、WHERE遗漏引发全表误更新、并发场景下丢失更新三大风险，需分别用COALESCE兜底、SELECT预验证、行锁或乐观锁等手段规避。
UPDATE语句中直接用SET col = col + N是否安全
完全安全，这是SQL标准语法，所有主流数据库（MySQL、PostgreSQL、SQL Server、SQLite）都支持。只要col是数值类型（INT、DECIMAL等），且不为NULL，表达式就能正常求值。如果col为NULL，结果仍是NULL——这不是bug，而是三值逻辑的必然行为。
NULL值导致更新“失效”的真实原因和绕过方式
常见现象：执行UPDATE t SET score = score + 10 WHERE id = 123后查不到变化，其实是score原值为NULL，计算结果还是NULL，看起来像没更新。
- 用
COALESCE兜底：SET score = COALESCE(score, 0) + 10 - 用
IFNULL（MySQL）或ISNULL（SQL Server）也可，但COALESCE跨库兼容性更好 - 注意：如果业务上
NULL有特殊含义（比如“未参与”，不应默认为0），就不能盲目替换，得先确认语义
WHERE条件遗漏引发全表误更新
这是最危险的操作失误。没写WHERE或条件恒真（如WHERE 1=1），会导致整列被批量加N，且不可逆（除非有备份）。
- 执行前务必确认
WHERE子句能精准定位目标行，建议先用SELECT验证：SELECT id, col FROM t WHERE ... - 在生产环境，优先使用带行数限制的测试语句（如MySQL的
LIMIT 1，但注意UPDATE ... LIMIT不是标准SQL，PostgreSQL需用CTE模拟） - 高危操作建议加事务包裹：
BEGIN; UPDATE ...; SELECT ROW_COUNT(); -- 确认影响行数再COMMIT;
并发场景下col = col + N可能丢失更新
两个事务同时读取同一行的col值（比如都是100），各自加10后写回，最终结果是110而非120——典型的“读-改-写”竞态。
- 用
SELECT ... FOR UPDATE（InnoDB/PostgreSQL）显式加行锁，强制串行化 - 或者改用原子操作：
UPDATE t SET col = col + 10 WHERE id = 123 AND col = 100（乐观锁，依赖已知旧值） - 注意：
col = col + N本身不自动加锁，锁由WHERE条件和隔离级别共同决定
实际执行时，类型隐式转换、负数溢出、精度截断这些细节比语法本身更值得盯紧。
