能，但仅在单表简单查询且直接 foreach 遍历时生效；关联查询、全量方法调用或非 PDO 无缓冲环境会退化为全量加载或分页模拟。

ThinkPHP 的 cursor() 方法真能省内存？

能，但只在特定条件下生效——它不加载全部结果到 PHP 内存，而是用 PDO 的 PDO::FETCH_CURSOR（实际依赖底层驱动支持）或模拟游标方式逐条 fetch。关键在于：必须配合 foreach 直接遍历，不能调用 toArray()、all() 或赋值给变量再循环，否则全量加载照旧。

• 常见错误现象：cursor() 后接 $list = $query->cursor()->all();，内存占用和 select() 无异
• 正确用法只能是：foreach ($query->cursor() as $row) { ... }
• 注意：MySQLi 驱动不支持原生游标，ThinkPHP 会退化为分页模拟（每次查 1000 条），仍比全量低，但不是真正服务端游标
• PostgreSQL 和部分 MySQL PDO 配置（PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false）下才可能触发底层无缓冲查询

为什么 cursor() 在关联查询里容易失效

因为 ThinkPHP 的关联预载入（with()）、聚合字段（group() + having()）、子查询等操作，会让 ORM 强制转成全量数组处理，cursor() 调用直接被忽略，静默回退到 select()。

• 典型场景：用 with('user') 查 100 万条订单并逐行处理用户信息 → 实际执行的是全量 JOIN 查询 + 全部加载
• 解决思路：拆开查，先 cursor() 拿主表 ID 列表，再分批（如每 5000 个 ID）查关联数据，避免单次大结果集
• 性能影响：关联越深、字段越多，cursor() 被绕过的概率越高；简单单表 where + field() 最稳定

cursor() 遇到事务或锁时的行为

它不会自动释放数据库连接或提前关闭结果集，如果在事务中使用且未及时消费完所有行，可能导致连接长时间占用、锁未释放，甚至触发 MySQL 的 wait_timeout 断连。

• 容易踩的坑：在 Db::transaction() 内部用 foreach ($query->cursor() as $row) 处理 10 万行，中间 sleep 或远程调用卡住 → 事务挂起，行锁持续持有
• 建议做法：把游标处理逻辑移出事务；如必须事务内处理，加超时控制和断点续传逻辑（记录最后处理的 id）
• 兼容性注意：SQLite 不支持无缓冲查询，cursor() 在其上等价于普通查询

替代方案：什么时候该放弃 cursor() 改用分块

当你要对数据做写操作（如批量更新状态）、需要前后行上下文、或查询本身已含复杂计算（如窗口函数、ORDER BY RAND()），cursor() 不仅无效，还可能因不可重复读导致逻辑错乱。

立即学习“PHP免费学习笔记（深入）”；

• 推荐改用 chunk()：例如 $query->chunk(5000, function ($rows) { ... })，可控、可中断、兼容所有驱动
• 参数差异：chunk() 按主键范围切片，要求表有自增/唯一递增字段；cursor() 无此限制但无法跳过已处理数据
• 真实代价：cursor() 看似“更轻”，但一旦涉及业务逻辑复杂度上升，分块的可维护性和稳定性反而更高

真正省内存的关键不在方法名，而在是否让每一行数据在被读取后立刻被 GC —— 这要求你别把它塞进数组、别缓存中间结果、别在循环体里做重 IO。不然换什么方法都白搭。