query builder 的核心价值在于可控性而非便捷性——需手动指定字段、条件、分页等，漏掉 where()、select() 或 chunk() 易致全表扫描、冗余数据或 oom。
Query Builder 为什么不是 DB::table()->get() 就完事
直接调用 DB::table('users')->get() 看似能查出数据，但实际项目里常踩三个坑：没加 ->where() 导致全表扫描、忘了 ->select() 拉回冗余字段、没用 ->chunk() 处理大数据量直接 OOM。Query Builder 的核心价值不在“能写”，而在“可控”——字段、条件、分页、连接、锁机制都得手动点名，漏一个就可能拖垮接口。
where() 多条件拼接的陷阱和写法差异
where() 看似简单，但 where('status', 1) 和 where(['status' => 1, 'deleted_at' => null]) 生成的 SQL 完全不同：前者是 AND 链式，后者是单个 WHERE 子句；更关键的是 whereNull('deleted_at') 才等价于 IS NULL，写成 where('deleted_at', null) 会变成 = NULL（永远为 false）。常见错误还有：
- 用
where('id', '>', $minId)代替whereRaw('id > ?', [$minId])—— 前者安全，后者易被绕过，但 raw 不校验类型 - 嵌套
where()写错括号层级，比如漏掉->where(function ($q) { ... })导致 AND 变成 OR - 时间范围用
whereBetween('created_at', [$start, $end])，但没确认字段是 datetime 还是 timestamp，时区不一致时查不到数据
join() 和 with() 别混着用，性能差十倍不止
join() 是 SQL 层面的 LEFT JOIN，一次查询拉平多表字段；with() 是 Eloquent 的 N+1 预加载，底层发多条语句再 PHP 合并。如果只是查列表+关联名称，用 DB::table('orders')->join('users', 'orders.user_id', '=', 'users.id')->select('orders.*', 'users.name')；如果要复用模型逻辑或做复杂关系过滤，才上 Order::with('user')->get()。容易忽略的点：
-
join()默认 INNER JOIN，想保留主表所有记录得显式写leftJoin() - 两个表都有
id字段时，select('*')会导致字段覆盖，必须用select('orders.id as order_id', 'users.id as user_id') -
with()在 Query Builder 里根本不能用——它只属于 Eloquent Model，DB::table()调用会报错Call to undefined method Illuminate\Support\Facades\DB::with()
limit()、offset() 和 paginate() 的真实开销在哪
limit(20)->offset(2000) 看似跳过前 2000 条，但 MySQL 仍要扫描并丢弃这 2000 行，数据量大时极慢；paginate(20) 底层会先执行 SELECT COUNT(*)，对无索引字段 count 可能卡死。真正轻量的分页方案是游标分页：where('id', '>', $lastId)->limit(20)。注意：
-
paginate()返回的是LengthAwarePaginator对象，不是数组，模板里用$data->links()渲染分页，别直接foreach -
simplePaginate()不 count 总数，只提供「下一页」链接，适合评论流这类无需总页数的场景 - 用
orderBy('id')配合游标分页时，确保id是主键且自增，否则翻页会漏/重数据
Query Builder 的复杂点从来不在语法，而在于每个方法背后对应的 SQL 行为是否真被你掌控——比如 update() 不触发模型事件、exists() 比 count() > 0 快得多、when() 动态加条件时忘记传参导致条件恒为 true。这些细节不写进日志，线上就只能靠慢查询日志反推。
