最稳的日志统计方式是直接用数据库count()查日志表，前提是日志已写入且created_at为标准DATETIME类型；Redis的INCR+TTL无法准确实现自然日统计，因过期时间基于创建时刻而非00:00，会导致数据跨天割裂。
直接用数据库 count() 查日志表是最稳的，但必须确保日志写入已就位且 created_at 字段是标准 DATETIME 类型。
为什么不能只靠缓存 key + TTL 做“每日统计”
Redis 的 INCR 配合 TTL=86400 看似能实现“按天归零”，但实际会出问题：如果某接口凌晨 2 点突然爆发流量，缓存 key 在当天任意时刻被创建，那它的过期时间就是“创建时刻 + 24 小时”，不是自然日。结果就是 00:00–23:59 的数据被切碎在两个 key 里，whereTime('created_at', 'today') 才真正对应业务上的“今日”。
- 缓存适合做实时频次（如最近 60 秒调了多少次），不适合替代日期维度聚合
- 想查“今天 / 昨天 / 本周”的请求量，必须依赖带时间字段的日志记录
- 如果你还没建日志表，先别急着写统计逻辑——得先有数据源
建表与中间件写入日志（ThinkPHP 6）
创建表 api_call_log，至少包含：id、api_path（VARCHAR 255）、created_at（DATETIME，默认 CURRENT_TIMESTAMP）。
在中间件中写入，不推荐裸调 Db::insert()，尤其高并发下：
- 用
Db::name('api_call_log')->strict(false)->insert()关闭严格模式，避免因字段缺失报错 - 把
$request->url()或$request->rule()标准化后再存：去掉 query string，统一小写，比如/api/v1/user/profile而不是/api/v1/user/profile?id=123 - IP 地址用
$request->ip()，它比$_SERVER['REMOTE_ADDR']更可靠（兼容代理头） - 别在中间件里做耗时操作；写入可推到 think-queue 队列，或用
go()协程（Swoole 环境）异步处理
按日统计的查询写法（关键细节）
ThinkPHP 的 whereTime() 是最简方案，但几个点容易踩坑：
-
whereTime('created_at', 'today')等价于BETWEEN '2026-08-17 00:00:00' AND '2026-08-17 23:59:59'，前提是created_at是 DATETIME 类型；如果是 TIMESTAMP 或 INT，会失效 - 要按接口分组统计当日次数：
Db::name('api_call_log')->whereTime('created_at', 'today')->group('api_path')->field('api_path,count(*) as count')->select() - 返回的
count是字符串，前端展示前必须转整型：(int)$item['count']，否则 ECharts 渲染失败 - 如果查“昨日”，用
whereTime('created_at', 'yesterday')；查“本周”，用whereTime('created_at', 'week')—— 这些底层都依赖 MySQL 的DATE()函数，别自己拼 SQL
不想建表？用 Redis + 定时任务模拟“按日统计”
真没数据库权限或不想加表，可用 Redis 模拟，但得接受“近似准确”：
- Key 设计为
api:daily:20260817:/v1/order/list，每天凌晨用命令行任务重置所有api:daily:YYYYMMDD:*的 key - 递增用
Cache::inc($key)，不用set($key, $val + 1)—— 后者非原子，高并发会丢数 - 定时任务脚本里用
Cache::get('api:daily:20260816:*')不行，KEYS命令会阻塞；改用SCAN游标分批拉取，再用DEL删除旧 key - 这个方案的问题：无法回溯历史（删了就没了），也没 IP、UA 等上下文，仅适合内部监控看趋势
真正难的不是写一行 count()，而是让每一行日志的 created_at 真正对齐你业务定义的“日”。时区、NTP 同步、MySQL 的 time_zone 设置，任何一个不对，查出来的“今日”就不是你想要的今日。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
