chunk() 在大数据量下变慢因依赖 OFFSET + LIMIT，ID 不连续时扫描行数线性增长；chunkById() 用 WHERE id > ? 游标查询，性能稳定，要求主键整型单调递增且不可混用 orderBy()。
为什么 chunk() 在大数据量下会变慢
因为 chunk() 默认用 OFFSET + LIMIT 实现，ID 不连续时跳过大量行，MySQL 扫描行数随偏移量线性增长。100 万条数据取第 1000 页（OFFSET 999990），实际可能扫描上百万行才凑够 10 条。
chunkById() 是更安全的替代方案
Laravel 7+ 原生支持按主键分块，底层不依赖 OFFSET，而是用 WHERE id > ? ORDER BY id LIMIT ? 游标式查询，每次只查下一批最小 ID 起的数据，性能稳定。
- 必须确保模型主键是整型且单调递增（默认
id满足） - 不能和
orderBy()混用——它自己固定按主键升序查，显式调用会报错或失效 - 回调函数里不要修改当前批次正在遍历的记录的
id值，否则可能漏数据或重复 - 示例：
$users = User::where('status', 1); $users->chunkById(1000, function ($users) { foreach ($users as $user) { // 处理逻辑 } }, 'id'); // 第三个参数可省略，默认就是 'id'
手动实现 ID 分块（兼容 Laravel
当需要按非主键字段（如 created_at）分块，或版本太低没 chunkById()，就得自己控制游标。
- 先查最小 ID：
User::min('id') - 循环中用
where('id', '>', $lastId)->limit(1000)查下一批 - 每次取完后更新
$lastId = $users->last()?->id，注意判空避免 null 报错 - 别用
count()判断是否结束——全表扫一遍抵消了优化效果；改用$users->count() 即可退出 - 如果表有软删除，记得加
withTrashed()或明确whereNull('deleted_at')，否则游标可能卡在“看不见”的记录上
容易被忽略的边界情况
ID 空洞本身不影响正确性，但若业务中存在高频删插、或用 UUID 当主键，chunkById() 仍能跑通，性能却可能退化：UUID 无序导致索引范围扫描效率下降，此时应优先考虑迁移到时间戳+序列组合键，或改用 created_at 字段分块并确保该字段有索引。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
