ThinkPHP游标查询怎么用_ThinkPHP模型大数据处理指南【操作】

先得说清楚一点：ThinkPHP 的 cursor() 并不是什么万能的分页替代品。它底层依赖数据库游标语义，这就要求排序字段必须是严格单调递增的（比如 id 或 create_time），而且得建好索引。降序（desc）直接不支持——原因很简单，游标靠的是“上一页最后一条的值”作为下一页起点，降序会导致这个起点不可靠，逻辑上就站不住脚。

一个常见的错误操作是，加了 ->order('id', 'desc') 还硬要套用 cursor()，结果查着查着就中断了，或者出现重复数据。正确的写法只有一种：->order('id', 'asc')。并且要确保这个字段没有 NULL 值，否则你连 MIN(id) 都拿不准，第一轮请求就可能漏掉数据。这些细节，但凡踩过一次坑，印象就深了。

另外还有几个关键限制需要留意：

• 不能用 whereRaw 干扰主键或排序字段的可预测性，比如 whereRaw('id % 2 = 0') 这种写法，会直接破坏游标的连续性。
• 关联查询（with()）、子查询、或者聚合字段（比如 count(*) as total），这些都会让 cursor() 自动降级为普通查询，失去了游标的性能优势。
• 如果你用的是 SQLite 驱动，那更要注意——它不支持服务器端无缓冲游标，所以 cursor() 本质上和 select() 没区别。

必须用 foreach 直接遍历，不能调 toArray() 或 all()

cursor() 返回的是一个 PHP 生成器（Generator），内存利用率高全靠“边 fetch 边 yield”这个机制。一旦你调用了 toArray()、all() 或者 count()，甚至把它赋值给一个变量后再去循环，框架就会把全部结果一次性加载进内存，这和普通查询就没什么两样了。

正确的做法非常固定：foreach ($query->cursor() as $row) { ... }。中间不能打断，不能缓存，也不能想着二次遍历。这就是游标查询的核心用法，也是它唯一正确的打开方式。

• 如果在事务中使用，要格外小心。如果你没把结果集消费完就结束了事务，那可能导致 MySQL 连接卡住、锁没有释放，甚至触发数据库的 wait_timeout 限制。
• 如果处理逻辑比较复杂，比如需要前后行对比，别硬撑着用游标，改用 chunk() 会更稳妥。
• 导出 CSV 之类的场景，游标确实很合适。但别忘了在循环里做 flush，或者设置 set_time_limit(0)，防止脚本超时。

chunk() 更通用，但默认按主键升序，可手动指定字段和方向

相比之下，chunk() 的兼容性要好得多，适用场景也更广。它底层是用 WHERE id > ? LIMIT N 模拟分页的，所以支持任意字段和升降序。

举个例子，如果我想按时间倒序分批处理：Db::table('log')->where('status', 1)->chunk(500, $callback, 'create_time', 'desc')。不过要注意，你指定的字段必须有索引，否则随着数据量增大，性能会急剧下降。

• 在闭包里返回 false 可以中断后续批次，适合那些需要条件提前退出的场景。
• WEB 请求下，慎用大批次（比如 chunk(10000)），很容易超时；这种操作更适合在命令行脚本里执行。
• 如果你的主键不是自增整型（比如 UUID），那就必须显式指定一个带索引的数值型字段，否则分页逻辑会完全错乱。

游标不自动释放连接，事务+长耗时处理要加断点续传

cursor() 不会主动关闭游标或者释放 PDO 连接。尤其在事务中逐行更新数据时，如果某次处理卡住了或者失败了，已经打开的结果集会一直占着连接，后续的请求可能会被阻塞。

真实线上环境的建议是：把游标的遍历逻辑移出事务。如果必须要在事务内执行，至少要做好两件事——记录最后成功处理的 id（用来做断点续传），并且给循环加一个最大执行时间限制（比如用 microtime(true) 来实时判断）。

最后，还有一点最容易被忽略：游标查询对“数据实时一致性”是没有保障的。如果遍历过程中，有其他进程插入或删除了排序字段范围内的数据，那就可能出现漏查或者重复的情况。这不是 bug，是游标本身的语义决定的。如果你需要强一致性，那就老老实实回到传统分页，或者在应用层加锁。