关联查询性能差主因是误用with()：嵌套过深、未建索引、条件预加载位置错误时反致更慢，应优先用withCount()、join()或hasManyThrough，并以EXPLAIN验证执行计划。
关联查询性能差，八成不是写法错，而是没搞清 with() 该不该用、怎么用、用到哪一级。
with() 预加载什么时候反而更慢
很多人一看到 N+1 就无脑加 with()，结果查 100 个用户，with('posts.comments.author') 生成 4 条独立 SELECT（users、posts、comments、author），每条都带 IN (1,2,3,...)，如果 post_id 或 comment_id 没索引，数据库直接全表扫描——压力从 SQL 变成 PHP 内存和序列化开销。
- 主表数据多（>500 行）、关联表大、嵌套 ≥3 层时，
with()往往不如手写join()+ 手动映射 -
withCount()比with()轻量得多，只要总数不要详情，优先选它 - 用
DB::select('EXPLAIN ...')看实际执行计划，type是ALL就别怪 Laravel，先加索引
条件预加载必须写对位置
想查“每个用户只加载已发布的文章”，不能写成：
$users = User::with(['posts' => function ($q) {
$q->where('status', 'published');
}])->get();
这会把所有用户都查出来，再过滤 posts —— 如果用户有 1000 个，但只有 3 个有发布文章，997 个用户的 posts 关系还是空数组，白查。
- 真正要筛出“有发布文章的用户”，得用
whereHas()先缩小主模型范围 - 条件预加载只适用于“主模型已确定，且关联数据一定存在”的场景，比如后台编辑页查当前用户的 profile 和 settings
- 字段也要精简：
with(['profile' => fn($q) => $q->select('user_id', 'bio')])，避免拉回整张宽表
深层关联别硬套 with()，试试 hasManyThrough 或 join()
User → Posts → Comments → Likes 这种四级关联，with('posts.comments.likes') 会发 4 次查询，每次 IN 参数还可能超长（MySQL 默认 max_allowed_packet 限制），直接报错或截断。
- 能用
hasManyThrough关系定义的（比如 User 的所有 comments），就别靠嵌套with硬顶 - 需要扁平化结果（如返回 user_name + post_title + comment_content）时，
join()是唯一靠谱选择 - 注意列名冲突：
join('posts', 'users.id', '=', 'posts.user_id')后，select('users.name', 'posts.title')必须显式限定，否则字段覆盖
load() 和 loadMissing() 不是救命稻草
控制器里先 $users = User::all()，再循环里 $user->load('posts') —— 这又变回 N+1。哪怕改成 $users->load('posts')，也只比循环好一点：它确实是单次 IN 查询，但前提是主集合已加载进内存，对大列表就是内存炸弹。
-
loadMissing()只防重复加载，不解决初始设计缺陷；它适合缓存后取模型再补关联的场景 - 真正该做的是：在最初查主模型时，就决定好哪些关联必须一起拿，哪些压根不该走 Eloquent（比如统计数走缓存，跨服务数据走 API）
- 别在视图层调
$user->posts—— 延迟加载开关开着，一个页面漏写with()，日志里立刻冒出几十条额外查询
最常被忽略的一点：优化不是堆技巧，而是判断“这个关联数据，此刻到底需不需要、值不值得、能不能一次拿全”。with() 是工具，不是信仰；join() 是手段，不是妥协；而 EXPLAIN 才是你该第一个打开的调试窗口。
