chunk()内存溢出主因是未控单块开销：模型实例、n+1查询、累积数组及pdo缓冲；chunkbyid()更稳因避offset、防漂移、倚索引；真正降内存需禁事件、精简预加载、用db::table替代模型并手动unset。
chunk() 为什么跑着跑着就内存爆了
不是 chunk() 失效，而是你没管住每一批的“真实开销”。它每次仍会把整块数据实例化成 Eloquent 模型，而模型自带属性、关系、事件监听器、静态缓存（Model::$instances），哪怕只查 500 条，也可能吃掉 20MB+ 内存。
- 回调里写
$user->posts却没->with('posts')？立刻触发 N+1，内存翻倍 - 累积数组如
$results[] = $user->toArray()，PHP 引用计数不归零，GC 不回收 - MySQL 驱动默认开启
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY，底层可能缓存全量结果集（尤其 PHP 7.4 以下） - 没关全局作用域或软删除干扰（如
->withTrashed()），查询条件变复杂，缓存更难清理
chunkById() 真正稳在哪几个点
chunkById() 不是“高级版 chunk()”，它是换了一套查询逻辑：用 WHERE id > ? ORDER BY id LIMIT ? 替代 OFFSET。这直接绕开了三个硬伤。
- 不依赖
OFFSET：大数据量下不会越往后越慢（OFFSET 1000000是全表扫描） - 防数据漂移：中间插入/删除记录，不会导致跳行或重复（
chunk()基于页码，删一行，下一页就偏了） - 天然走索引：只要
id有主键或唯一索引，就是范围扫描，不回表 - 注意：第三个参数要显式传，比如
User::chunkById(500, $callback, 'user_id')，兼容非默认主键名
真正压内存的实操组合拳
单靠换函数没用。必须同时砍掉模型层冗余、切断缓存链路、释放引用。
- 关事件：
User::withoutEvents(function () { User::chunkById(500, $callback); }); - 砍预加载：
->with(['profile'])只加真需要的，别写->with('posts.comments.tags') - 绕过模型：
DB::table('users')->select('id', 'email')->chunkById(1000, $callback)，跳过实例化开销 - 手动清场：回调末尾加
unset($users); Model::flushEventListeners(); Model::clearBootedModels(); - 确认 PDO 配置：
'options' => [PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false]，禁用客户端缓冲
cursor() 别当“万能省内存方案”乱用
cursor() 内存恒定≈1 条记录，但代价是彻底放弃写能力——你不能在循环里调 $user->update() 或 $user->delete()，底层是无状态游标流，一读即过。
- 适合场景：只读导出、统计、生成报表
- 不适合场景：批量更新、状态流转、关联写入
- 注意：MySQL 默认仍是全结果集拉到 PHP 进程内存里，只是用
yield逐行吐，不是“边查边读” - 如果真要流式写，得拆成两步：先
cursor()拿 ID 列表 → 再用DB::table()->whereIn('id', $ids)->update(...)批量操作
主键不连续、有 UUID、复合主键、或软删除字段干扰时，chunkById() 和 cursor() 都可能漏数据。这时候得回归原始手段：按时间范围分片（created_at BETWEEN ? AND ?）+ 记录断点。
