count() 和 sum() 用错地方，查出来是 null 而不是 0
MySQL 默认对空结果集返回 NULL，Laravel 的 count()、sum() 等聚合方法底层调用的是原生 SQL 的 COUNT()、SUM()，但很多人没意识到：当没有匹配记录时，sum() 返回 NULL，而 count() 返回 0 —— 这个差异直接导致 PHP 层报 Trying to perform arithmetic on null 错误。
实操建议：
对 sum()、avg()、max()、min()，统一用 ?? 0 或 coalesce() 处理空值：$total = Order::where(‘status’, ‘paid’)->sum(‘amount’) ?? 0;避免在查询链中直接做运算，比如 ->sum(‘price’) * 1.1，一旦 sum() 是 NULL，整个表达式崩掉如果必须在数据库层补 0，可用 DB::raw(‘COALESCE(SUM(amount), 0)’)，但注意这会让 Eloquent 返回原始数组，丢失模型实例
groupBy() 后 select() 字段不明确，MySQL 8.0 直接报错
Laravel 写 groupBy() 很容易只写 select(‘user_id’)->groupBy(‘user_id’)，但在 MySQL 8.0+ 严格模式下，只要 SELECT 列表里有非分组字段（比如 created_at），就会触发 Expression #1 of SELECT list is not in GROUP BY clause 错误。
实操建议：
要么所有 select() 字段都在 groupBy() 中出现，要么只选聚合字段（count()、sum() 等）和分组字段不要依赖 select(‘*’) + groupBy()，它在 MySQL 5.7 以前可能“侥幸通过”，但语义错误且结果不可靠需要同时查用户信息和统计数？用子查询或 withCount() 更安全：User::withCount([‘orders as paid_orders’ => function ($q) { $q->where(‘status’, ‘paid’);}])->get();
withCount() 看似简单，但关联条件写错就漏数据
withCount() 是 Laravel 提供的便捷聚合方式，但它本质是 LEFT JOIN + COUNT，不是子查询。如果你在闭包里写了会影响主表筛选的条件（比如 whereNotNull(‘deleted_at’)），它不会过滤掉主表记录，但会把计数变 0 —— 表面看“都查到了”，实际统计值失真。
实操建议：
只在 withCount() 闭包里写真正属于关联表的过滤条件，比如 $q->where(‘status’, ‘active’)涉及软删除时，别在闭包里加 withoutTrashed() —— 它无效；正确做法是确保关联关系本身已配置 ->withTrashed() 或默认排除逻辑要统计“每个用户最近一笔订单金额”，withCount() 做不了，得用 selectSub() 或原生子查询
大表 count(*) 慢，别硬扛，先看要不要精确值
对千万级订单表执行 Order::where(‘status’, ‘shipped’)->count()，可能卡住几秒甚至超时。这不是 Laravel 的问题，而是 MySQL 对 COUNT(*) 在无索引或范围条件下必须扫行。
实操建议：
分页场景下，优先用 simplePaginate()，它不查总数，只判断“是否有下一页”后台报表类需求，如果允许误差 ±5%，可改用 SELECT TABLE_ROWS FROM information_schema.TABLES 查估算值（需权限）真要精确且高频，给常用查询条件建覆盖索引，比如 (status, id)，让 COUNT(*) 走索引最左前缀
聚合查询最容易被忽略的，其实是「空值语义」和「SQL 模式差异」——同一段代码在本地 SQLite、测试环境 MySQL 5.7、生产 MySQL 8.0 上表现可能完全不同。别只盯着 Laravel 文档，顺手 toSql() 看一眼生成的 SQL，比猜强得多。
评论(0)