Laravel模型关联预加载？预加载如何实现？-Laravel-PHP中文网

预加载通过with()或load()方法解决N+1查询问题，减少数据库查询次数，提升性能。例如查询20篇文章及作者时，未预加载需21次查询，而使用with('user')仅需2次。还可通过withCount()统计关联数量、loadMissing()避免重复加载、$with属性设置默认预加载，但需警惕过度预加载导致内存溢出，应按需加载并结合实际场景优化。

laravel模型关联预加载？预加载如何实现？

Laravel模型关联预加载，简单来说，就是一种优化数据库查询的策略，它能有效解决我们常说的N+1查询问题，通过在执行主查询时一并加载相关联的数据，而不是在需要时才逐条去查询，从而显著提升应用的性能。实现预加载的核心方法主要就是使用

with()

登录后复制

或

load()

登录后复制

。

解决方案

我们在开发基于Laravel的应用时，经常会遇到一个经典的性能陷阱——N+1查询问题。想象一下，你有一个

Post

登录后复制

模型，每个

Post

登录后复制

都属于一个

User

登录后复制

。当你查询20篇文章，然后遍历它们并显示每篇文章的作者名字时，如果不做任何处理，Laravel会先执行一条查询获取20篇文章，然后为每一篇文章再单独执行一条查询去获取其作者信息，这样一来，总共就会有1（文章）+ 20（作者）= 21条数据库查询。这显然是低效的。

预加载就是为了解决这个问题。它通过一次或少数几次查询，就将所有需要的数据（包括关联数据）从数据库中取出来。

最直接的实现方式就是使用

with()

登录后复制

方法。

// 假设我们想获取所有文章及其作者
$posts = App\Models\Post::with('user')->get();

foreach ($posts as $post) {
    echo $post->title . ' by ' . $post->user->name;
}

登录后复制

这段代码，

with('user')

登录后复制

告诉Laravel，在查询

posts

登录后复制

的时候，也一并把它们关联的

User

登录后复制

数据加载进来。这样，无论有多少篇文章，Laravel都只会执行两条查询：一条获取所有文章，另一条获取所有相关联的用户。

如果你的模型实例或集合已经存在，你也可以使用

load()

登录后复制

方法来预加载：

$posts = App\Models\Post::all(); // 此时N+1问题已存在

// 可以在现有集合上加载关联关系
$posts->load('user');

foreach ($posts as $post) {
    echo $post->title . ' by ' . $post->user->name;
}

登录后复制

这对于你已经获取了一部分数据，但后续需要用到其关联关系，又不想重新查询整个集合时非常有用。

对于更复杂的场景，比如多层嵌套的关联，

with()

登录后复制

也能很好地处理：

// 假设Post有一个User，User有一个Profile
$posts = App\Models\Post::with('user.profile')->get();

foreach ($posts as $post) {
    echo $post->title . ' by ' . $post->user->name . ' (' . $post->user->profile->bio . ')';
}

登录后复制

这样会执行三条查询：文章、用户、用户档案。

有时候我们还需要对预加载的关联关系添加额外的约束，比如只加载活跃的作者：

$posts = App\Models\Post::with(['user' => function ($query) {
    $query->where('status', 'active');
}])->get();

登录后复制

这样，只有状态为

active

登录后复制

的用户才会被预加载进来。

为什么我们总要提Laravel的N+1查询问题？它到底有多“致命”？

说实话，N+1查询问题在Laravel（乃至任何ORM框架）中，几乎是我在代码审查时最常指出的性能隐患之一。它之所以“致命”，并非总是一开始就让你的应用崩溃，而是像温水煮青蛙一样，在不经意间蚕食着应用的性能和用户体验。

它的核心问题在于，当你需要获取一个主模型集合及其关联模型时，如果没有预加载，系统会先执行一次查询获取主模型集合（N=1），然后对于集合中的每一个主模型实例，再单独执行一次查询去获取其关联模型。如果主模型集合中有M个实例，那么总共就会是1 + M次查询。

举个例子，假设我们有一个电商网站，要展示100个订单，每个订单都有一个对应的顾客信息：

度加剪辑

度加剪辑（原度咔剪辑），百度旗下AI创作工具

查看详情

// 未使用预加载
$orders = App\Models\Order::all(); // SELECT * FROM orders; (1次查询)

foreach ($orders as $order) {
    echo "订单号: " . $order->id . ", 顾客: " . $order->customer->name;
    // 每次访问 $order->customer 都会触发一次 SELECT * FROM customers WHERE id = ?;
    // 如果有100个订单，这里会执行100次查询
}
// 总共：1 + 100 = 101次数据库查询

登录后复制

这101次查询，意味着什么？

数据库连接开销： 每次查询都需要建立、维护、关闭数据库连接（或从连接池获取），这本身就是资源消耗。
网络延迟： 每次查询请求都要通过网络发送到数据库服务器，再等待结果返回。如果你的应用服务器和数据库服务器不在同一台机器上，或者网络状况不佳，这累积起来的延迟是相当可观的。100次小的网络往返，可能比1次大的往返耗时更多。
数据库服务器负载： 频繁的小查询会给数据库服务器带来不必要的压力，尤其是当并发用户量大时，可能会导致数据库连接池耗尽、CPU飙升，甚至服务崩溃。
内存与CPU： 虽然单次查询的数据量可能不大，但频繁地执行查询、解析结果集，也会占用应用服务器的CPU和内存资源。

N+1问题最“狡猾”的地方在于，它在开发初期，数据量小的时候，可能根本不显眼。你可能只有几条数据，1+5次查询和1+1次查询看起来没太大区别。但一旦数据量增长到几十、几百、几千，甚至上万，这个性能瓶颈就会突然变得非常突出，让你的页面加载时间从几十毫秒飙升到几秒甚至几十秒。我见过不少项目，上线后因为N+1问题导致页面响应慢如蜗牛，最后不得不紧急回溯代码进行优化。所以，在开发阶段就养成预加载的好习惯，是避免未来踩坑的有效手段。

除了

with()

登录后复制

和

load()

登录后复制

，还有哪些“花式”预加载技巧能让代码更优雅高效？

除了最常用的

with()

登录后复制

和

load()

登录后复制

，Laravel还提供了一些非常有意思的“花式”预加载技巧，它们能让你的代码在特定场景下更优雅、更高效，避免写一些冗余的逻辑，或者说，让ORM层能帮你做更多事情。

聚合函数预加载：

withCount()

登录后复制

,
withExists()
登录后复制
,
withAvg()
登录后复制
,
withSum()
登录后复制
等有时候我们并不需要完整的关联模型数据，而只是想知道关联模型的数量、是否存在，或者某个字段的平均值、总和。这时候，

withCount()

登录后复制

系列方法就派上用场了。

// 获取所有文章，并直接在每个文章对象上附加评论数量
$posts = App\Models\Post::withCount('comments')->get();

foreach ($posts as $post) {
    echo $post->title . ' 有 ' . $post->comments_count . ' 条评论。';
}

// 还可以计算平均分
$products = App\Models\Product::withAvg('reviews', 'rating')->get();
foreach ($products as $product) {
    echo $product->name . ' 平均评分: ' . $product->reviews_avg_rating;
}

登录后复制

这比先预加载所有评论，再手动

count()

登录后复制

要高效得多，因为它直接在数据库层面进行聚合计算。

延迟预加载（Lazy Eager Loading）：
```
loadMissing()
```
登录后复制
```
loadMissing()
```
登录后复制
是一个非常实用的方法，它只会在关联关系尚未加载时才执行预加载。这在某些情况下，比如你可能已经通过其他方式加载了部分关联，或者想避免重复加载时非常有用。
```
$user = App\Models\User::find(1);
// 假设 user->posts 已经被某些操作加载过了

// 只有当 posts 关联尚未加载时，才会执行查询
$user->loadMissing('posts');
```
登录后复制
模型默认预加载：
```
$with
```
登录后复制
属性如果你知道某个模型在几乎所有情况下都需要预加载某个关联关系，你可以直接在模型类中定义
```
$with
```
登录后复制
属性。
```
// App/Models/Post.php
class Post extends Model
{
    protected $with = ['user']; // 每次查询Post时，都会自动预加载User

    // ...
}

// 现在，无论你如何查询Post，User都会被自动加载
$posts = App\Models\Post::all(); // 已经包含了User数据
```
登录后复制
这非常方便，但也要注意，它会增加所有
```
Post
```
登录后复制
查询的开销，即使在某些场景下你并不需要
```
User
```
登录后复制
数据。所以，使用时要权衡利弊。
条件式预加载（Conditional Eager Loading） 有时候，我们只在满足特定条件时才需要预加载某个关联。虽然
```
with()
```
登录后复制
闭包可以实现，但
```
whenLoaded()
```
登录后复制
方法在模型实例上也能提供类似的便利。
```
$posts = App\Models\Post::all();

// 假设我们只在特定条件下才需要加载评论
if (some_condition_is_true()) {
    $posts->load('comments');
}
```
登录后复制
这更像是手动控制，但逻辑清晰。
通过全局作用域（Global Scopes）实现预加载 虽然不直接是预加载方法，但全局作用域可以用来确保某个关联总是被加载，或者在加载时应用特定约束。这与
```
$with
```
登录后复制
属性类似，但更灵活，可以定义更复杂的逻辑。
```
// 定义一个作用域，确保每次查询User时都预加载Profile
// App/Models/User.php
protected static function booted()
{
    static::addGlobalScope('withProfile', function (Builder $builder) {
        $builder->with('profile');
    });
}
```
登录后复制
这样，每次
```
User::all()
```
登录后复制
都会自动带上
```
profile
```
登录后复制
。如果需要绕过，可以使用
```
User::withoutGlobalScope('withProfile')->get()
```
登录后复制
。

这些技巧各有侧重，选择哪种方式取决于具体的业务需求和对性能的考量。在我看来，灵活运用它们，能够让你的Laravel应用在数据访问层面更加精细和高效。

预加载是不是“万金油”？什么时候不应该使用，或者说，使用时需要注意什么？

预加载无疑是解决N+1查询问题的利器，但它绝非“万金油”，也不是越多越好。在我看来，任何优化手段都有其适用场景和潜在的副作用。不恰当的预加载，反而可能带来新的性能问题，甚至比N+1问题更难察觉。

什么时候不应该使用预加载，或需要特别注意：

过度预加载（Over-eager Loading）导致内存爆炸： 这是预加载最常见的陷阱之一。如果你一股脑地预加载了所有可能的关联关系，而这些关系在当前请求中大部分都不会被用到，那么你就是在浪费资源。例如，你查询了1000篇文章，每篇文章都预加载了
```
User
```
登录后复制
、
```
comments
```
登录后复制
、
```
tags
```
登录后复制
、
```
categories
```
登录后复制
、
```
attachments
```
登录后复制
等十几个关联。如果
```
comments
```
登录后复制
和
```
attachments
```
登录后复制
每个都有几十条数据，那么1000篇文章可能会加载几十万条关联数据到内存中。这会导致：
- 内存占用飙升： PHP进程的内存消耗会急剧增加，可能导致内存溢出（Out Of Memory）。
- 数据传输量大： 即使数据库查询次数减少了，但单次查询传输的数据量会变得非常巨大，同样会增加网络延迟和数据库负载。
- CPU开销： Laravel在将这些原始数据映射到模型实例时，也会消耗CPU资源。
我的建议是： 永远只预加载你当前页面或当前逻辑中确实需要的关联关系。如果某个关联只有在用户点击某个按钮后才需要，那么就考虑懒加载（
```
$post->load('comments')
```
登录后复制
）或者通过API异步加载。
关联数据量极大时： 如果某个关联关系的数据量非常庞大，比如一个用户可能有几万条日志记录，那么预加载
```
user->logs
```
登录后复制
可能会带来灾难性的后果。在这种情况下，更好的做法是：
- 分页加载： 只加载部分关联数据，例如
```
$user->logs()->paginate(10)
```
  登录后复制
  。
- 使用聚合函数： 如果只需要统计数量，使用
```
withCount()
```
  登录后复制
  而不是加载所有数据。
- 重新思考数据结构： 某些“一对多”关系在实际应用中可能更像“一对无限多”，此时可能需要考虑将部分数据独立存储或设计更高效的查询方案。
复杂查询与多重
```
JOIN
```
登录后复制
的替代方案： 虽然预加载在很多情况下能避免N+1，但如果你的业务逻辑需要非常复杂的过滤、排序，并且涉及多个关联模型的字段，有时直接使用
```
JOIN
```
登录后复制
语句，或者通过
```
DB::table()
```
登录后复制
构建查询，甚至编写原始SQL，可能会比ORM的预加载更高效、更灵活。ORM在处理极度复杂的交叉查询时，生成的SQL可能不是最优的。
```
$with
```
登录后复制
属性的滥用： 在模型中使用
```
protected $with = ['relation'];
```
登录后复制
固然方便，但它意味着每次查询该模型时，都会无条件地加载这些关联。如果你的模型在很多场景下并不需要这些关联，那么这就会变成一种“过度预加载”。我个人倾向于在需要时显式调用
```
with()
```
登录后复制
，或者只对那些几乎总是需要的、且数据量不大的关联使用
```
$with
```
登录后复制
。

总结来说，预加载的精髓在于“按需加载”和“适度加载”。 它是一个性能优化的工具，但不是一个可以无脑使用的“开关”。在使用预加载时，我们应该始终保持一种审慎的态度，结合实际的业务场景、数据量和性能监控数据来做决策。一个好的实践是，在开发过程中就多留意SQL日志，看看Laravel实际执行了多少条查询，以及这些查询的耗时，这样才能更准确地判断预加载是否带来了真正的价值。

以上就是Laravel模型关联预加载？预加载如何实现？的详细内容，更多请关注php中文网其它相关文章！