MySQL超大表禁用chunk()因OFFSET分页性能衰减且内存溢出，应改用基于有序主键的游标分页（如cursorPaginate()），需显式orderBy()、避免多字段排序、注意软删除和锁策略。
为什么不能用 chunk() 处理超大表
当表有 500 万+ 行，chunk() 会越来越慢甚至失败——它底层靠 OFFSET 分页，越往后查，MySQL 越要扫描前面所有行。同时内存占用随 chunk size 线性增长，容易触发 Fatal error: Allowed memory size exhausted。
Cursor 分页不依赖 OFFSET，而是用上一批最后一条记录的主键值（或唯一有序字段）作为下一页起点，查询稳定、无性能衰减、内存恒定。
- 必须确保排序字段（如
id）有索引且严格递增（推荐用自增主键） - 不能用
ORDER BY RAND()或含 NULL 的字段做游标依据 - 数据实时写入时，可能跳过或重复（需业务容忍“近实时”）
cursorPaginate() 怎么用才不报错
直接调 cursorPaginate() 很容易遇到 InvalidArgumentException: You must specify at least one order column —— 它强制要求显式声明 orderBy()，且字段必须可索引、非空、单调。
正确写法：
立即学习“PHP免费学习笔记（深入）”；
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
$users = User::orderBy('id')
->cursorPaginate(1000); // 每页 1000 条
- 只支持单字段
orderBy()，多字段（如orderBy('created_at', 'id')）会抛异常 - URL 中的游标参数是 base64 编码的字符串（如
?cursor=eyJpZCI6MTAwMH0），不要手动解析或拼接 - 如果模型启用了软删除，记得加
withTrashed()或onlyTrashed()，否则游标可能“断层”
手动实现游标迭代：绕过分页器封装
当需要完全控制循环逻辑（比如边查边处理、写入另一张表、避免 HTTP 响应超时），建议不用 cursorPaginate()，改用手动游标推进：
$lastId = 0;
$limit = 1000;
while (true) {
$batch = User::where('id', '>', $lastId)
->orderBy('id')
->limit($limit)
->get();
if ($batch->isEmpty()) break;
foreach ($batch as $user) {
// 处理单条记录
processUser($user);
}
$lastId = $batch->last()->id;
}
- 务必用
where('id', '>', $lastId)+orderBy('id')组合，不能反过来，否则索引失效 - 每次循环只 fetch 一次，不缓存整个结果集，内存始终可控
- 若主键不是
id（比如用 UUID），得换成带索引的有序时间字段（如created_at），并注意 MySQL 的 datetime 精度问题
游标遍历和事务、锁怎么共存
在长循环中直接更新/删除数据，容易触发死锁或锁等待超时——因为 InnoDB 默认对扫描范围加间隙锁（gap lock），而游标查询本身是范围扫描。
稳妥做法：
- 读取阶段禁用锁：
User::where('id', '>', $lastId)->orderBy('id')->sharedLock()->get()（仅读，不阻塞写） - 写操作拆离：先查 ID 列表，再用
whereIn('id', [...])批量更新，减少锁持有时间 - 避免在循环内开启事务；如必须，把事务粒度控制在单 batch 内，并设
DB::transaction(..., 3)防重试失败 - 线上环境务必加
sleep(0.01)或usleep(10000)，防止 CPU 扛满影响其他请求
游标真正的难点不在语法，而在你是否清楚自己正在跳过哪些行、是否接受最终一致性、以及有没有为锁和并发留出余量。
