paginate()在百万数据下卡死，因先执行count(*)全表扫描，再用大offset跳读需遍历前n行；chunk()连表时报“未知排序字段”因无法识别主键归属，须显式传入带表别名的排序字段如'u.id'。
ThinkPHP 处理百万级数据时，paginate() 和 chunk() 默认行为几乎必然导致性能崩盘或内存溢出——这不是配置问题，是 SQL 模式本身不适用。
为什么 paginate() 在百万数据下会卡死
默认 paginate() 会先执行 COUNT(*)，再用 LIMIT offset, size 跳读。MySQL 在大 offset 下必须扫描并丢弃前 N 行，IO 和 CPU 双重浪费。100 万数据查第 500 页（offset=99900）时，响应可能超 10 秒甚至超时。
-
COUNT(*)不走索引时全表扫描，耗时随数据量线性增长 -
LIMIT 99900, 20实际要定位到第 99920 行，引擎仍需遍历索引树 - TP6 的
paginate()无法跳过COUNT，哪怕你只想要“下一页”按钮
连表查询中 chunk() 报 “未知排序字段” 怎么办
连表后框架无法自动识别主键归属，chunk() 默认尝试调用 $this->getPk()，但多表上下文里它可能返回 id 而非 users.id，最终生成的 ORDER BY id 语句因歧义被 MySQL 拒绝。
- 必须显式传入带别名的排序字段，例如
'u.id'（对应Db::table('users u')） - 不能依赖
alias()后的别名自动推导，TP6 不解析 alias 关系 - 若使用
join()且主表字段有重名（如两个表都有created_at），field()必须明确限定，否则chunk()构造的SELECT语句会语法错误
游标分页替代 paginate() 的实操要点
用 where('id', '>', $last_id) + order('id ASC') + limit($size) 替代 paginate()，可将响应稳定在毫秒级，且完全规避 COUNT。
-
order方向必须和游标条件严格一致：>对应ASC，对应 <code>DESC，反向会导致漏数据 - 前端不能传任意
page参数，只能维护上一页最后一条的id值 - 模型中封装时，避免在方法内做
count()或total()计算，否则失去优化意义 - 如果业务强依赖总条数（如后台报表），应在低峰期异步统计并缓存，而非每次请求实时计算
chunk() 内存泄漏最常被忽略的点
回调函数内未释放的大对象（如临时数组、PDOStatement、第三方 SDK 实例）会在每批次处理后持续驻留，1000 批次后内存可能暴涨数倍，最终触发 OOM。
- 在
chunk()回调末尾手动unset($largeArray)，尤其处理 Excel 导出、JSON 解析等场景 - 避免在回调内创建新模型实例并长期持有，改用
Db::raw()或原生 SQL 更新 - CLI 环境下建议配合
gc_collect_cycles()主动触发垃圾回收，每 100 批调用一次 - 不要在
chunk()中开启事务后忘记commit()或rollback()，未关闭事务会锁表并拖慢后续批次
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
