分页循环处理大数据的核心是按批拉取、逐批处理以控制内存和数据库负载。推荐用chunk()流式分批（如Laravel/CakePHP）或游标分页替代offset分页，配合必要字段查询与批量操作，避免N+1查询。
用分页循环处理大数据遍历，核心是避免一次性加载全部数据到内存，改用“按批拉取、逐批处理”的方式。关键不在于“翻页”，而在于控制每次数据库交互的数据量和内存驻留量。
用 chunk() 流式分批处理（推荐用于后台任务）
CakePHP、Laravel 等主流框架都提供 chunk() 方法，它底层基于游标滚动（PDO fetch），每批只在内存中保留当前批次的数据，处理完自动释放。
- 每次只取 100–500 条，例如：
$query->chunk(300, function ($rows) { foreach ($rows as $row) { // 做导出、同步、更新等操作 } }); - 不会触发
fetchAll()，不会 OOM - 无需手动管理偏移或游标，框架自动处理语句重用和游标释放
- 适合定时任务、数据迁移、批量推送等场景
用游标分页替代 offset 分页（推荐用于 API 分页）
当需要向前端提供“下一页”能力（比如列表接口），不要用 page=1000，而是用上一页最后一条的排序字段值作为起点：
- 假设按
created_at DESC, id DESC排序，上一页最后一条是：['created_at' => '2026-10-05 08:30:22', 'id' => 99876] - 下一页查询写成：
WHERE (created_at < '2026-10-05 08:30:22') OR (created_at = '2026-10-05 08:30:22' AND id < 99876) ORDER BY created_at DESC, id DESC LIMIT 20
- 客户端传
cursor=base64(...)，服务端解码后拼条件 - 必须确保数据库有对应复合索引，如
INDEX idx_created_id_desc (created_at DESC, id DESC)
只查必要字段 + 限制条数
全字段 SELECT * 会放大序列化、网络传输、内存占用三重开销：
- 改用
find('list')->select(['id', 'status'])->limit(1000) - 或原生查询：
SELECT id, name FROM users WHERE ... LIMIT 500 - 配合
toArray()也比全对象安全，尤其字段含大文本或 JSON 时
避免在循环里反复执行查询
别写这种低效代码：
for ($i = 0; $i < 10000; $i++) {
$row = $table->find()->where(['id' => $i])->first(); // ❌ 一万次查询
}应改为：
- 一次查 ID 列表（覆盖索引）
- 再用
IN批量查详情（注意 MySQL 的IN有长度限制，建议每批 ≤ 1000） - 或直接
JOIN子查询（延迟关联优化）
本质上，分页循环不是为了“好看地翻页”，而是让系统扛得住百万级数据的一次性扫表压力。选对方式，内存稳、数据库快、代码也干净。
