cursor() 更省内存因其返回生成器,逐行构造模型并释放,而get()一次性加载全部数据;但需注意mysql默认缓冲查询、必须orderby、不支持with预加载及更新操作等限制。

cursor() 为什么比 get() 更省内存
因为 cursor() 返回的是 PHP 生成器(Generator),每次迭代只从 PDO 结果集中 fetch 一行,处理完就释放该模型实例;而 get() 会把全部结果一次性加载为 Eloquent 模型数组,内存占用随数据量线性增长。50 万条记录用 get() 可能吃掉 1.2GB 内存,cursor() 始终维持在 8–12MB。
但要注意:MySQL 默认使用客户端游标,整个结果集其实已从服务端传输到 PHP 进程内存中——只是 PHP 层用生成器延迟构造模型对象。真正“流式拉取”需配合 MySQL 的 useCursor() + PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false,Laravel 并未默认启用。
- 必须显式调用
orderBy('id'),否则抛出RuntimeException: You must specify an order clause - 不支持
with()预加载,关联数据得在循环里按需查(或改写为 JOIN) - 不能调用
count()、paginate()或任何触发查询执行的方法,否则生成器失效 - 返回的模型是只读的,调用
$user->save()会报错或静默失败
cursor() 循环里怎么安全做更新操作
直接在 cursor() 循环中调用 save() 或 update() 是危险的——游标依赖底层 PDOStatement 的稳定状态,修改行为可能干扰 fetch 流程,导致跳行、重复或中断。
正确做法是把游标遍历和更新解耦:先用 cursor() 提取 ID 列表(或关键字段),再用 whereIn('id', $ids) 批量更新。或者换用 chunkById()——它专为更新设计,按主键范围切片,不依赖游标机制。
PHP中文网提供Laravel 13.2.0版本下载,Laravel框架 是基于 PHP 8.3+ 的高性能框架,官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索,支持属性驱动开发与队列路由,大幅提升开发效率。相比旧版,13.2.0 优化了缓存 TTL 管理与实时通信,无需 Redis 即可横向扩展。作为现代 Web 开发首选,它兼顾安全与极速体验,助您快速构建企业级应用。
- 若必须边读边更,改用
chunkById(1000, function ($users) { ... }),它内部用WHERE id BETWEEN ? AND ?,稳定且支持模型修改 - 避免在
cursor()循环里调DB::transaction(),事务会延长连接时间,增加锁等待风险 - 高并发写入场景下,
cursor()+ 单条update()容易触发间隙锁冲突,建议加lockForUpdate()显式锁定,但会显著降低吞吐
cursor() 和 cursorPaginate() 不是一回事
cursor() 是流式遍历接口,面向后台任务(如导出、通知);cursorPaginate() 是分页响应接口,面向 API 分页(如前端下拉加载)。两者底层逻辑不同,不能混用。
cursorPaginate() 要求严格单字段升序 orderBy(),返回带 nextCursor 的分页器;cursor() 不关心分页,也不生成游标字符串,就是纯 foreach。
-
cursorPaginate()在 Laravel 9.2+ 才原生支持,8.x 需手动实现(用where('id', '>', $lastId)) -
cursorPaginate()不返回total(),响应里不能塞total字段,否则前端逻辑错乱 -
cursor()不解析 URL 中的cursor=xxx参数,它根本不走 HTTP 请求上下文 - 软删除模型用
cursor()时,默认不包含已软删记录,要加withTrashed()才能读到
容易被忽略的索引和字段陷阱
游标依赖排序字段的**唯一性 + 单调性 + 索引覆盖**,三者缺一不可。用 created_at 当游标字段却没建索引?查询会全表扫描,比 chunk() 还慢。
更隐蔽的问题是字段值重复:created_at 在毫秒级并发下极易重复,导致 WHERE 条件匹配多行,下一页漏掉部分记录。这时必须补二级排序,比如 orderBy('created_at')->orderBy('id'),但注意 cursorPaginate() 不支持多字段,只能手动实现。
- 主键不是
id(比如 UUID)?别硬用,换成有索引的created_at,并确保 MySQLdatetime(3)精度足够 -
updated_at绝对不能当游标字段——它可回滚、可批量更新,顺序完全不可控 - 复合索引要匹配排序顺序:
ORDER BY created_at DESC, id DESC对应索引应为(created_at, id),且方向一致 - 字段含 NULL?MySQL 认为所有 NULL 相等,游标定位会失效,务必加
whereNotNull('created_at')










