Laravel Eloquent ORM中 chunk () 与 chunkById () 详解及选择

管理员 发布于 4年前   597

随着应用程序的扩展,使用 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 特性的 chunkById 方法,我们 [看到](github.com/laravel/framework/blob/...) 存储的最后一条记录的 ID(请记住,我们按 ID 升序排列)被存储并在下一个要运行的查询中用作参数。

转:https://dev.to/ryancco/faster-eloquent-chunking-3lc0

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!

该博客于2020-12-7日,后端基于go语言的beego框架开发
前端页面使用Bootstrap可视化布局系统自动生成

是我仿的原来我的TP5框架写的博客,比较粗糙,底下是入口
侯体宗的博客

      订阅博客周刊

文章标签

友情链接

HouTiZong
侯体宗的博客
© 2020 zongscan.com
版权所有ICP证 : 粤ICP备20027696号
PHP交流群
侯体宗的博客