UPDATE语句中字段自增应直接写SET col = col + 1，无需先查后改；需注意NULL处理、WHERE精准定位、避免应用层计算，并利用ON DUPLICATE KEY UPDATE实现插入或自增。
UPDATE 语句中直接用字段自身参与计算
SQL 中实现字段自增更新，本质是让 UPDATE 的 SET 子句引用当前行的原值。比如把 view_count 字段加 1，写成 SET view_count = view_count + 1 即可生效，不需要先查再改。
常见错误是误以为必须显式读取旧值（如用子查询或变量），这不仅低效，还可能在并发下出错。直接计算最安全、最高效。
- MySQL、PostgreSQL、SQL Server、SQLite 都支持这种写法
- Oracle 需注意：若字段为
NULL，NULL + 1结果仍是NULL，应先用NVL()或COALESCE()处理 - 避免写成
SET view_count += 1—— 这不是标准 SQL，仅部分方言（如 SQL Server）支持，移植性差
WHERE 条件必须明确，防止全表误更新
自增操作一旦执行就不可逆，漏写或写错 WHERE 可能导致整张表的计数器被批量加 1，线上事故高发点。
典型场景是文章阅读量更新：UPDATE articles SET view_count = view_count + 1 WHERE id = 123。这里 id = 123 是关键约束。
- 务必确认
WHERE能精准定位单行（如主键或唯一索引列） - 测试阶段建议先用
SELECT模拟：运行SELECT id, view_count FROM articles WHERE id = 123确认目标行存在且正确 - 不要依赖应用层判断“是否存在再更新”——应用和数据库之间存在竞态，应由数据库原子性保证
并发环境下计数器重复累加问题
多个请求同时执行 UPDATE ... SET count = count + 1 WHERE id = X，数据库默认会加行锁，保证最终结果正确（如两个并发请求都会使 count + 1，总效果是 +2）。这点无需额外干预，但需理解其行为边界。
容易踩坑的是“读-改-写”模式：先 SELECT count，再应用层算新值，最后 UPDATE。这会导致丢失更新（lost update）。
- 绝对避免在应用代码里做
count + 1计算后回写 - 如果需要条件自增（例如只在用户未点赞时才增加赞数），用
WHERE表达条件，而不是靠应用逻辑分支 - 高吞吐场景下，频繁自增可能成为热点行瓶颈，这时要考虑分片计数（如按时间/哈希拆分）或异步聚合
MySQL 中使用 INSERT ... ON DUPLICATE KEY UPDATE 实现“不存在则插入，存在则自增”
当需要初始化计数器并支持后续累加（比如统计某用户对某商品的点击次数），INSERT ... ON DUPLICATE KEY UPDATE 是更简洁的方案，避免先查后插/更的两步逻辑。
前提是表上有唯一约束（如 (user_id, item_id) 联合唯一索引）：
INSERT INTO click_stats (user_id, item_id, count) VALUES (1001, 2002, 1) ON DUPLICATE KEY UPDATE count = count + 1;
- 第一次插入：新增一行，
count为 1 - 后续相同
(user_id, item_id)插入：触发UPDATE，count自增 - PostgreSQL 对应语法是
INSERT ... ON CONFLICT DO UPDATE，逻辑一致 - 注意：该语句返回的受影响行数在 MySQL 中可能是 1（插入）或 2（更新），不能直接用它判断是否新增
NULL 值处理和唯一约束缺失导致的意外全表更新。写完 SQL 务必用 EXPLAIN 看执行计划，确认 WHERE 走了索引。 
