跳转到主内容
极星编程网:以代码为星,赴技术山海!

Laravel聚合查询怎么用_Laravel统计查询方法【教程】

Laravel聚合需谨慎:sum/avg返回null须用??0处理;groupBy在MySQL 8.0+要求SELECT非聚合字段必须全在GROUP BY中;withCount闭包条件写错会导致统计为0且无提示。 直接说结论:Laravel聚合不是“写完就跑”的快捷键,
sum()
、
avg()
返回
null
而非
0
,
groupBy()
在 MySQL 8.0+ 会因字段不匹配直接报错,
withCount()
闭包里写错条件会导致统计全为 0 却不提示——这三个点踩中任一,结果就不可信。 sum/avg/max/min 返回 null 怎么办 MySQL 对空结果集的
SUM()
、
AVG()
默认返回
NULL
,Laravel 不做转换,直接透传。PHP 层一旦参与运算或 JSON 输出,立刻崩。 错误写法:
$total = Order::where('status', 'paid')->sum('amount') * 1.1
—— 没记录时
sum()
是
null
,PHP 报
Trying to perform arithmetic on a null value
安全写法:
$total = Order::where('status', 'paid')->sum('amount') ?? 0
数据库层补零(需放弃模型实例):
DB::raw('COALESCE(SUM(amount), 0)')
,但结果是数组,
->first()
后得用
['coalesce' => 0]
这种键取值
count()
是例外:永远返回整数,空结果也是
0
,不用判空 groupBy() 在 MySQL 8.0+ 报错 Expression #1 of SELECT list is not in GROUP BY clause 这是严格模式下的语法校验,不是 Laravel bug。你写了
select('user_id', 'name')->groupBy('user_id')
,但
name
既不在
GROUP BY
列表里,也不是聚合字段,MySQL 就拒绝执行。 安全写法一:所有
select()
字段都出现在
groupBy()
中,例如
->select('user_id', 'status')->groupBy('user_id', 'status')
安全写法二:只选分组字段 + 聚合字段,例如
->select('user_id')->selectRaw('COUNT(*) as order_count')->groupBy('user_id')
别依赖
select('*')->groupBy('id')
:语义错误,旧版 MySQL 可能“凑合过”,但结果不可靠,且新版直接拒 如果要用
selectRaw()
做分组聚合,确保
SELECT
列表里每个非聚合字段都在
GROUP BY
中显式列出 withCount() 闭包里加条件为什么统计全是 0
withCount()
底层是
LEFT JOIN
+
COUNT
,闭包里的条件只作用于关联表的匹配逻辑。写错位置,主表数据还在,但计数全变 0。 Laravel 13.2.0 PHP中文网提供Laravel 13.2.0版本下载,Laravel框架 是基于 PHP 8.3+ 的高性能框架,官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索,支持属性驱动开发与队列路由,大幅提升开发效率。相比旧版,13.2.0 优化了缓存 TTL 管理与实时通信,无需 Redis 即可横向扩展。作为现代 Web 开发首选,它兼顾安全与极速体验,助您快速构建企业级应用。 下载 有效条件(只对关联表生效):
withCount(['orders as paid_orders' => function($q) { $q->where('status', 'paid'); }])
无效条件(误写主表字段或软删除判断):
$q->whereNotNull('deleted_at')
—— 它不会被放进
ON
子句,反而让
LEFT JOIN
失效,变成
INNER JOIN
效果,没订单的用户直接消失 软删除应提前在关系定义中处理,比如
public function orders() { return $this->hasMany(Order::class)->withTrashed(); }
,而不是在闭包里补 想过滤主表(如只查 active 用户),必须写在主查询里:
User::where('active', 1)->withCount('orders')->get()
大表 count(*) 慢怎么优化 百万级表上裸用
count(*)
,尤其带复杂
WHERE
条件时,极易触发全表扫描。索引不一定能救,因为
COUNT(*)
需要确认每一行是否满足条件。 优先用
simplePaginate()
替代
paginate()
:它跳过总数计算,只查当前页数据,响应快得多 为
WHERE
条件字段加索引,比如
status
、
created_at
,能显著减少扫描行数 避免在聚合字段上用函数:
whereRaw('YEAR(created_at) = 2024')
会让索引失效,改用
whereBetween('created_at', ['2024-01-01', '2024-12-31 23:59:59'])
软删除表记得建
(deleted_at, id)
覆盖索引,否则
COUNT(*) WHERE deleted_at IS NULL
仍要逐行判断 最常被忽略的是闭包条件的作用域和
GROUP BY
字段的完整性——它们不出错时一切正常,一出错就是静默失真,查半天才发现数据不对。

相关文章