Laravel Eloquent chunk () 与 chunkyById () 的区别

Laravel

转载自 Laravel 论坛：https://learnku.com/laravel/t/46881

随着应用程序的扩展，使用Laravel Eloquent处理大量数据库记录可能变得越来越困难。导致内存不足异常并总体上降低应用程序速度。这是为什么？

从数据库中获取结果时，您又将数据拉到内存中。以这个代码片段为例

Post::all()->each(function ($post) {
    // ...
});

这将导致以下查询，将posts表中的所有记录加载到内存中

select * from posts;

通常对于具有少量记录的表，这是绝对可以接受的。但是，随着成千上万的帖子的积累，您最终将开始遇到Web服务器的内存资源限制。

Laravel中常见的方法是使用Eloquent的 (通过 BuildsQuery) chunk() 一种方法，该方法获取固定数量的记录，将较大的集合分解为更多的可消耗块。

Post::chunk(1000, function ($post) {
    // ...
});

尽管这看起来不错，但有很多改进和要注意的地方。

首先，设想以下情形：您正在从数据库中获取Post记录以更新也在where子句中使用的属性

Post::where('published_at', '<', now())->chunk(1000, function ($post) {
    $post->update('published_at', now());
});

尽管是人为的，但它例证了一个非常现实的问题，其中这样的查询将导致无限循环，因为在下一次执行查询时，published_at属性将始终小于now（）（假设精度为秒使用MySQL的timestamp列类型或类似名称）。

其次，存在查询性能及其对数据库服务器的影响的问题。上面的代码将导致类似于以下内容的查询

select * from posts order by posts.id asc limit 1000 offset 9000

由于删除的记录和附加的查询约束，MySQL无法直接转到偏移量，因此，此查询必须有效地选择前10,000条记录，以仅返回最后选择的1,000条记录。可以想象，这无法很好地扩展到成千上万行。这将导致数据库服务器使用不必要的资源，从而降低了应用程序中所有其他查询的速度。

为了防止无法预料的陷阱并提高数据库服务器性能，我们可以使用Eloquent chunkById 的方法

Post::where('published_at', '<', now())->chunkById(1000, function ($post) {
    $post->update('published_at', now());
});

上面的代码段将导致类似于以下内容的查询

select * from posts where published_at < '2019-09-11 12:00:00' and id > 9000 order by id asc limit 1000

为什么将此方法视为“更好”？

a）它允许MySQL完全跳过前9000条记录（假设是顺序记录）
b）由于where子句中的id约束，我们将不再重新选择已经更新的记录

深入探讨BuildsQueries特性的chunkyById方法，我们[看到]（https://github.com/laravel/framework/blob/6.x/src/Illuminate/Database/Concerns/BuildsQueries.php#L92-L107) 存储的最后一条记录的ID（请记住，我们按ID升序排列）被存储并在下一个要运行的查询中用作参数。

讨论请前往专业的 Laravel 论坛：https://learnku.com/laravel/t/46881