应采用分批查询替代全量select，如chunk()游标分页或where id > last_id主键分页，避免limit+offset性能退化及内存溢出。
结果集太大直接 select() 会内存溢出、超时、卡死——这不是配置调大就能解决的，得换思路：不一次性捞全量，改用游标分批或主键分页拉取。
为什么 limit + offset 在大数据量下会越来越慢
MySQL 的 offset 实际是先扫描前 N 行再丢弃，100 万条数据查第 99 万条起的 100 条，它仍要定位到第 99 万行起点，IO 和 CPU 开销陡增。TP 默认的 paginate() 底层就走这个逻辑，翻到后面页基本不可用。
- 真实场景中，
offset > 5000就该警惕性能拐点 - 如果表有自增
id或时间字段（如created_at），优先用「where id > last_id」替代offset -
paginate()不适合导出、同步、后台批量任务，只适合前端分页展示
用 chunk() 流式处理避免内存爆炸
chunk() 是 ThinkPHP 提供的原生分批查询方案，它底层用游标 + limit 拉取，每次只载入一批记录到内存，处理完自动释放，适合清洗、推送、统计等后台任务。
- 必须传闭包回调，不能链式写成
$query->chunk(500)->each(...) - 默认每批 100 条，建议根据单条数据大小调到 200–500；太小 IO 多，太大内存压力回升
- 闭包内不要修改当前批次正在遍历的模型实例的主键值，否则可能漏数据或重复
- 示例：
$UserModel->chunk(300, function ($users) { foreach ($users as $user) { // 处理单条，比如发消息、更新状态 $user->update(['synced' => 1]); } });
手动主键分页（适用于导出或跨服务同步）
当需要完全控制分页逻辑（比如导出 CSV、同步到 ES），且主键连续或有索引，就自己维护 last_id：
立即学习“PHP免费学习笔记（深入）”；
- 首次查：
$list = $model->where('id', '>', 0)->order('id ASC')->limit(500)->select(); - 后续查：
$list = $model->where('id', '>', $last_id)->order('id ASC')->limit(500)->select(); - 每次取
$list最后一条的id作为下轮$last_id，注意判空防止死循环 - 若主键不连续（如软删除后 ID 跳变），改用带时间字段的组合条件：
whereTime('created_at', '>', $last_time)
大结果集下别碰 toArray() 和 all()
这两个方法会强制把全部结果加载进 PHP 内存，哪怕你只是想 count 或取某个字段。实际开发中常见误用：
- 写
$data = $query->select()->toArray()后再array_column($data, 'id')—— 改用$query->column('id') - 为“保险起见”调
$query->select()->all()，其实select()返回的就是 Collection，all()是冗余操作 - 导出前用
count()判断总数？对千万级表慎用，改用估算：SHOW TABLE STATUS LIKE 'table_name'查Rows字段（误差可接受）
真正卡住的往往不是语法，而是没意识到「查全量」这个动作本身在大数据场景下就是反模式。分批不是妥协，是必要设计——游标位置、主键边界、内存释放节奏，每个细节都影响任务能否跑通。
