如何优化ThinkPHP字段统计避免计数器更新错误？

本文共计1000个文字，预计阅读时间需要4分钟。

ThinkPHP的`setInc`和`setDec`方法看似简单，直接使用时容易在高并发下出现错误、数据不准确、缓存不同步等问题。这些问题主要源于方法本身并未处理并发、事务边界和缓存同步，这些问题需要在调用时额外考虑。

为什么不能在 save() 后手动 $model->hot++ 再 save()

这种写法本质是“读-改-写”三步，在 PHP 层做加法，不是原子操作：

• 并发请求同时读到 hot=10，各自加 1 后都写回 11，实际应为 12
• $model->save(['hot' => $model->hot + 1]) 会覆盖其他字段，除非你显式传入全部要更新的字段
• 若模型启用了自动时间戳或事件钩子，save() 可能触发额外逻辑，干扰统计意图

setInc / setDec 必须配合 where 使用，且不能复用模型实例

这两个方法不接受条件参数，只作用于当前已设置的查询条件。常见陷阱是模型对象被复用：

• 错误写法：$tag = TagModel::find(123); $tag->where('status', 1)->setInc('hot'); —— 这里 where('status', 1) 是冗余且危险的，主键查单条不该加额外条件；更糟的是，如果后续用同一个 $tag 实例查列表，where 条件会被合并残留
• 正确姿势：用全新查询构造器，如 TagModel::where('id', 123)->setInc('hot') 或 Db::name('tag')->where('id', 123)->inc('hot')->update()
• 字段类型必须是 INT 或 BIGINT；若为 NULL，部分 ThinkPHP 版本调用 setInc 会报错，建表时设默认值 DEFAULT 0

延迟更新（setLazyInc）是个坑，别在关键路径用

ThinkPHP 提供了带延迟参数的 setLazyInc('field', 1, 60)，但它依赖内存缓存暂存 SQL，不适用于生产环境的计数场景：

立即学习“PHP免费学习笔记（深入）”；

• 延迟期间进程重启或 FPM worker 释放，计数直接丢失
• 同一模型对象后续调用 select() 时，延迟更新残留的 where 条件会被合并进新查询，导致 SQL 错误（比如 WHERE id=5 AND status=0 被插进列表页查询）
• 没有失败重试机制，网络抖动或 DB 拒绝连接时，计数静默失败
• 真要异步，应走消息队列 + 独立消费进程，而不是靠框架级延迟

热度排序加 LIMIT 时，order('hot desc') 不够用

只按 hot 排序再 limit 10，同热度标签会被随机截断，分页结果不稳定：

• 必须补二级排序，例如 order('hot desc, id desc') 或 order('hot desc, updated_time desc')
• hot 字段务必加索引：ALTER TABLE `tag` ADD INDEX idx_hot (hot);
• 若热度更新频繁，建议建联合索引 idx_hot_id (hot, id)，避免排序时回表
• 缓存该结果时，别缓存整个数组，而是用 cache('top_tags_v2', $data, 300) 显式设 5 分钟过期，并在每次 setInc 后清掉这个 key

最易被忽略的一点：setInc 是 DB 层原子操作，但缓存读取是另一条路径。更新后不清缓存，前端永远看不到新热度；清缓存时没考虑分布式部署下的多节点一致性，又会导致短暂不一致。这三步——DB 自增、删缓存、补二级排序——少走一步，线上就出数据毛刺。