不能写update table set counter++，因sql标准不支持++操作符，mysql等数据库会报语法错误；正确写法是counter = counter + 1，需注意null处理、where精准定位及并发安全。
UPDATE 语句本身不支持自增语法（如 ++），但可以通过表达式（如 counter = counter + 1）安全实现计数器功能；直接用 SELECT ... FOR UPDATE 或事务控制是避免并发覆盖的关键。
为什么不能写 UPDATE table SET counter++ WHERE id = 1？
这是常见误解——SQL 标准里没有 ++ 这种操作符，MySQL、PostgreSQL、SQL Server 等都不支持。写成这样会直接报错，比如 MySQL 返回 ERROR 1064，PostgreSQL 报 syntax error at or near "+"。
真正可行的是显式计算：counter = counter + 1，它依赖字段当前值做原子更新。
- 必须确保该字段允许为
NULL或已初始化（否则NULL + 1得NULL） - 推荐在建表时设默认值：
counter INT NOT NULL DEFAULT 0 - 若需严格递增且不跳号（如订单号），
UPDATE+ 表锁不是好方案，应改用序列或应用层协调
如何防止并发更新导致计数丢失？
多个请求同时执行 UPDATE t SET cnt = cnt + 1 WHERE id = 1，在默认隔离级别下可能产生“读-改-写”竞态：两个事务读到相同旧值，各自加 1 后写回，结果只+1 而非+2。
解决方式取决于数据库：
- MySQL InnoDB：加
SELECT ... FOR UPDATE显式加行锁（需在事务中） - PostgreSQL：同样用
SELECT ... FOR UPDATE，或直接靠UPDATE的行级锁（其UPDATE本身就自动加锁，但需确认无索引导致锁表） - SQLite：用
BEGIN IMMEDIATE防止写冲突 - 通用稳妥做法：把计数逻辑封装进存储过程或应用层重试（如捕获唯一键冲突/影响行数为 0 时重试）
带条件的计数器更新怎么写才可靠？
例如“仅当状态为 active 时才增加点击数”，看似简单，但容易漏掉影响行数判断。
正确姿势是检查 UPDATE 返回的影响行数：
UPDATE pages SET views = views + 1 WHERE id = 123 AND status = 'active';
然后在代码里判断执行结果：
- 影响行数为 1 → 更新成功
- 影响行数为 0 → 条件不满足（如 status 不是 active，或 id 不存在），不应视为失败，而是业务逻辑跳过
- 绝不依赖
SELECT COUNT(*)再UPDATE，那是典型竞态源头
如果需要“不存在则插入，存在则更新”，考虑 INSERT ... ON DUPLICATE KEY UPDATE（MySQL）或 INSERT ... ON CONFLICT DO UPDATE（PostgreSQL）。
性能和可维护性要注意什么？
高频计数器（如每秒数千次更新）会成为热点行瓶颈，尤其在单行上反复锁争抢。
- 避免让所有计数挤在一条记录里；可按时间分片（如按小时存
views_20240520_14）或哈希分桶（shard_id = id % 16）再聚合查询 - 不要在计数器字段上建高频查询的索引——写放大严重，除非你真要按计数值排序且数据量小
- 如果只是统计用途，异步写入（如发消息到 Kafka，由 Flink 汇总）比强一致性同步更新更可持续
最常被忽略的一点：计数器字段没设 NOT NULL 且初始未赋值，上线后某次 UPDATE 把整列悄悄变成 NULL，查半天才发现是 NULL + 1 导致的静默失效。
