应使用 chunk() 或 find('list') 避免 oom：chunk(200) 流式处理，内存恒定；find('list')->select(['id','name'])->limit(1000) 减少字段开销；游标分页需手动构造 where 条件，而非依赖 page 参数。
用 find('list') 或 chunk() 避免全量加载到内存
CakePHP 的 find('all') 默认把整页结果一次性 fetchAll 到 PHP 内存，百万级数据分页时容易 OOM。真实场景中你并不需要一次拿到全部 20 条记录再处理——尤其当只是导出、同步或批量更新时。
更稳妥的做法是用流式遍历：
-
chunk(200, function ($rows) { /* 每批200条处理 */ })：底层调用 PDO::fetch + 游标滚动，内存恒定，适合后台任务 -
find('list')->select(['id', 'name'])->limit(1000)：只取两字段，减少序列化开销，配合toArray()也比全字段安全 - 避免在循环里反复调用
$query->execute()或手动拼 SQL；CakePHP 的chunk()已自动管理语句重用和游标释放
where() + order() 构造游标条件，别依赖 page 参数
CakePHP ORM 本身不内置游标分页逻辑，得自己拼 WHERE。关键不是“第几页”，而是“从哪条之后开始”。比如按 created_at DESC, id DESC 排序，上一页最后一条是 ['created_at' => '2026-09-28 14:22:01', 'id' => 88721]，下一页查询就得写成：
->where([
'OR' => [
'created_at '2026-09-28 14:22:01',
['created_at =' => '2026-09-28 14:22:01', 'id 88721],
]
])
注意三点：
- 方向必须和
order()严格一致（DESC 对应，ASC 对应 <code>>），否则索引失效 - 复合排序时，WHERE 条件要覆盖所有排序字段，防止时间重复导致漏数据
- 别用
page=1000去算 offset —— CakePHP 的paginate()默认就是 offset 分页，大数据量下它会悄悄执行LIMIT 9999, 20，直接拖垮数据库
确保索引覆盖 order + where 字段，否则游标变慢查询
游标分页快，前提是数据库能用索引跳到起点。如果只对 id 建了主键索引，但查询是 ORDER BY created_at DESC, id DESC WHERE created_at ，MySQL 可能放弃索引、走 filesort。
必须建复合索引：
- 升序游标：
INDEX idx_created_id (created_at, id) - 降序游标（MySQL 8.0+）：
INDEX idx_created_id_desc (created_at DESC, id DESC)，否则优化器可能不走索引 - 用
EXPLAIN看type是否为range，Extra不含Using filesort或Using temporary
客户端传 cursor 而非 page，服务端别做校验兜底
游标分页的语义是“继续往后翻”，不是“跳到某页”。所以前端必须传 cursor=base64_encode(json_encode(['created_at' => ..., 'id' => ...]))，后端解码后直接用于 WHERE，不要额外验证这个 cursor 是否“合法”或“存在”。
原因很实际：
- 验证 cursor 是否对应真实记录，等于又查了一次数据库，抵消游标优势
- cursor 是上一页末尾值，哪怕被删了，WHERE 条件自然返回空结果，前端显示“到底了”即可
- 加校验还引入竞态：A 用户翻页时，B 删除了 cursor 对应那条，校验失败，但业务本就不该强依赖中间状态
真正容易被忽略的是游标字段的类型精度 —— 时间戳带毫秒？数据库存的是 DATETIME 还是 TIMESTAMP？PHP date('Y-m-d H:i:s') 会丢掉微秒，导致游标条件漏掉同秒内多条记录。统一用 microtime(true) 或数据库原生 NOW(6) 生成并透传。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
