Db::query()执行原生SQL，灵活安全需手动转义；Db::table()->select()为链式查询，适合简单场景但复杂聚合易错。统计单值用->value()，分组统计用->select()配合->column()。
ThinkPHP 6 的 Db::query() 和 Db::table()->select() 区别在哪
直接用 Db::query() 写原生 SQL 是最灵活的统计方式，尤其涉及多表 JOIN、GROUP BY + 聚合函数（如 COUNT()、SUM()、AVG()）时；而 Db::table()->select() 是链式查询构造器，适合简单条件过滤后查全字段，但复杂聚合容易写错或性能不佳。
常见错误是强行用 select('COUNT(*) as total') 却忘了加 ->column('total') 或 ->value('total')，结果返回空数组或报错 Undefined index: total。
- 统计单个值（如总请求数）优先用
->value()，它返回标量，不是数组 - 多字段分组统计必须用
->select()，且记得->column()或->toArray()显式取结果 -
Db::query()中的 SQL 必须手动转义变量，否则有 SQL 注入风险；Db::table()自动参数绑定，更安全
按日期统计请求量：date_format() 和 FROM_UNIXTIME() 怎么选
ThinkPHP 默认时间字段是 int 类型的时间戳，不是 datetime。所以不能直接 GROUP BY request_time，得先转成日期格式。MySQL 里 FROM_UNIXTIME(request_time, '%Y-%m-%d') 更稳妥；DATE_FORMAT() 只接受 datetime 类型，强转可能出错。
示例：查最近 7 天每日请求量
立即学习“PHP免费学习笔记（深入）”；
$data = Db::query(
"SELECT FROM_UNIXTIME(create_time, '%Y-%m-%d') AS date, COUNT(*) AS count
FROM think_request_log
WHERE create_time >= ?
GROUP BY date
ORDER BY date DESC",
[time() - 86400 * 7]
);- 注意
create_time字段名要和你日志表实际字段一致，别硬套request_time - 时间范围用参数绑定（
?），别拼字符串，避免注入和时区问题 - 如果数据库用的是 datetime 类型，改用
DATE(create_time)更轻量，不用格式化函数
统计接口调用 Top10：ORDER BY + LIMIT 容易漏掉 COUNT(*) 别名
查调用量最高的 10 个接口路径，SQL 很简单，但 ThinkPHP 链式写法容易在 group() 后忘写 field()，导致返回所有字段，拖慢查询甚至 OOM。
推荐写法：
$top10 = Db::table('think_request_log')
->field('path, COUNT(*) AS cnt')
->where('create_time', '>=', time() - 86400 * 30)
->group('path')
->order('cnt', 'desc')
->limit(10)
->select();-
field()必须显式写出聚合字段和别名，否则COUNT(*)不会被识别为列 - 别名
cnt在order()里直接用，不加反引号也不加表前缀 - 如果
path值过长（比如带完整 query string），建议先用SUBSTRING_INDEX(path, '?', 1)截断，否则分组不准确
并发统计不准？记得加 where 条件过滤有效状态
真实场景中，日志表常混着 404、500、重定向等无效请求，直接 COUNT 会虚高。关键是要定义“有效请求”——通常是 status BETWEEN 200 AND 299 或排除特定码。
- 不要只写
where('status', '>=', 200)，得闭区间，否则包含 304、302 等非成功响应 - 如果用了 Nginx 日志或中间件埋点，注意 status 字段可能存的是字符串，需用
CAST(status AS UNSIGNED)转整型再比较 - 高并发下，count 查询本身也可能变慢，可考虑给
(create_time, status)加联合索引
聚合统计真正难的不是写 SQL，而是确认数据口径是否一致：前端上报、网关记录、应用层日志三者 status 定义是否统一，字段是否被截断或脱敏。这点不厘清，代码写得再漂亮也没用。
