Laravel 中为什么不建议滥用 chunk()？以及 chunkById() 的正确使用场景

在 Laravel 开发中，很多人处理大数据量时都会使用 chunk() 分批读取数据，认为这样既节省内存又安全。但在实际业务开发中，如果使用不当，chunk() 反而可能导致数据遗漏、重复处理甚至业务异常。

最近在 ERP 系统开发过程中，就遇到了因为 chunk() 导致部分 SKU 未被处理的问题。本文详细介绍 chunk() 和 chunkById() 的区别，以及为什么很多场景下并不建议直接使用 chunk()。

什么是 chunk()

chunk() 用于分批查询数据，避免一次性加载大量数据到内存。

例如：

User::chunk(1000, function ($users) {
    foreach ($users as $user) {
        // 处理用户
    }
});

Laravel 实际执行的 SQL 类似于：

SELECT * FROM users LIMIT 1000 OFFSET 0;

SELECT * FROM users LIMIT 1000 OFFSET 1000;

SELECT * FROM users LIMIT 1000 OFFSET 2000;

通过不断增加 Offset 来实现分页读取。

chunk() 存在的问题

1. 更新数据时可能出现数据遗漏

假设有如下代码：

User::where('status', 0)
    ->chunk(100, function ($users) {

        foreach ($users as $user) {
            $user->status = 1;
            $user->save();
        }

    });

初始数据：

id	status
1	0
2	0
…	…
200	0

第一次查询：

SELECT * 
FROM users
WHERE status = 0
LIMIT 100 OFFSET 0;

获取 1~100。

处理后：

1~100 => status=1
101~200 => status=0

第二次查询：

SELECT *
FROM users
WHERE status = 0
LIMIT 100 OFFSET 100;

此时满足条件的数据只剩：

101~200

共100条。

但 Offset 仍然是 100。

结果：

查询结果为空

导致：

101~200 永远不会被处理

这就是典型的数据遗漏问题。

---

2. 数据新增导致重复处理

如果在处理过程中有新数据插入：

INSERT INTO users ...

Offset 会发生偏移。

可能出现：

部分数据被重复读取

或者：

部分数据被跳过

---

3. 大 Offset 性能差

例如：

LIMIT 1000 OFFSET 100000

MySQL 实际需要：

扫描 101000 条记录
丢弃前 100000 条
返回最后 1000 条

随着 Offset 增大：

查询越来越慢

尤其百万级数据表十分明显。

---

chunkById() 的工作原理

Laravel 提供了更安全的方案：

User::chunkById(1000, function ($users) {

    foreach ($users as $user) {
        // 处理逻辑
    }

});

底层 SQL：

第一次：

SELECT *
FROM users
WHERE id > 0
ORDER BY id
LIMIT 1000;

第二次：

SELECT *
FROM users
WHERE id > 1000
ORDER BY id
LIMIT 1000;

第三次：

SELECT *
FROM users
WHERE id > 2000
ORDER BY id
LIMIT 1000;

通过主键递增读取，而不是 Offset。

---

chunkById() 的优势

不会因数据修改导致遗漏

例如：

User::where('status', 0)
    ->chunkById(100, function ($users) {

        foreach ($users as $user) {
            $user->status = 1;
            $user->save();
        }

    });

即使状态被修改：

id > 上次最大ID

仍然可以继续向后读取。

不会出现 Offset 偏移问题。

---

查询性能稳定

使用：

WHERE id > ?

能够利用主键索引。

即使数据量达到：

100万
1000万
1亿

性能依然稳定。

---

chunkById() 也不是万能的

必须有递增字段

默认使用：

id

如果主键不是连续递增：

uuid

则无法直接使用。

---

不能按复杂排序处理

例如：

->orderBy('created_at')

此时：

chunkById()

可能不符合业务需求。

因为它本质上依赖：

WHERE id > last_id

而不是排序字段。

---

官方推荐的替代方案

Laravel 官方文档明确建议：

如果在遍历过程中会更新记录，优先使用：

chunkById()

优点：

• 内存占用更低
• 不会出现 Offset 问题
• 代码更优雅

---

实际项目中的建议

适合使用 chunk()

场景：

• 数据不会被修改
• 只是导出数据
• 只是统计分析
• 数据量不大

例如：

生成报表
导出 Excel
统计订单数

---

优先使用 chunkById()

场景：

• 批量更新
• 批量修复数据
• 定时任务
• 队列消费
• SKU 状态处理
• 用户状态同步

例如：

批量修改商品状态
批量发送消息
批量同步库存
批量生成记录

---

总结

很多开发者认为：

chunk() = 大数据处理标准方案

实际上并非如此。

两者核心区别：

方法	原理	是否可能漏数据	性能
chunk()	LIMIT + OFFSET	是	越来越慢
chunkById()	WHERE id > last_id	否	稳定

因此在实际业务开发中：

读取后需要更新数据
优先 chunkById()

仅查询导出
可使用 chunk()

尤其是在 ERP、订单系统、库存系统、SKU 生命周期管理等场景中，chunk() 引发的数据遗漏问题