直接用paginate()查百万级数据会内存溢出或超时，因其底层依赖LIMIT offset导致MySQL全扫前N行，且默认执行慢COUNT(*)；应改用chunk()流式处理或基于主键的游标分页（如where('id','>',$lastId)），避免offset性能退化。
直接用 paginate() 查百万级数据，PHP 进程大概率会内存溢出或超时——这不是调大 memory_limit 就能解决的，得从查询逻辑上换掉 LIMIT offset, size 这套机制。
为什么 paginate() 在大数据量下会崩
ThinkPHP 默认的 paginate() 底层走的是 LIMIT offset, size，而 MySQL 执行时必须先扫描并跳过前 offset 行。查第 100 万页（offset=9999990）时，它真的一行行扫了近一千万行才开始取数据，CPU 和 I/O 压力陡增，PHP 进程常在超时前就因内存耗尽被 kill。
- 哪怕你把
memory_limit改成 2G，也挡不住 MySQL 返回的临时结果集撑爆 PHP 内存 -
count(*)统计总条数在千万级表里本身就很慢，还可能锁表，paginate()默认会执行它 - 前端传个
page=5000，后端不校验就直接喂给paginate()，等于主动触发雪崩
用 chunk() 或游标分页替代 paginate()
ThinkORM 4 / ThinkPHP 6+ 提供了真正适合大数据的流式处理方式：chunk() 和基于主键的游标分页。它们不依赖 offset，也不一次性加载全部结果。
-
chunk(1000, function ($users) { /* 每次只处理 1000 条 */ })：适合后台导出、数据迁移等场景，内存恒定，但不返回分页结构 - 游标分页示例（按
id升序）：Db::name('user')->where('id', '>', $lastId)->order('id ASC')->limit(20)->select()，拿到最后一条的id传给下一页 - 必须确保
id（或时间戳字段）有索引、唯一、非空；不能跳转任意页码，只支持「下一页」连续翻阅 - 若需「上一页」，改用
WHERE id ，再手动反转结果数组
导出 Excel 时内存爆炸的实操解法
导出接口常见写法是先 select() 全量数据，再 foreach 拼装 Excel —— 这在 10 万行以上基本必炸。真实可行的路径是「分批查 + 分批写 + 合并」。
立即学习“PHP免费学习笔记（深入）”；
- 用
chunk()遍历主表，每次取 500~1000 条，查出关联字典数据后立即写入临时.xlsx文件（推荐xlswriter扩展，比phpspreadsheet内存友好得多） - 把字典表、配置类数据提前缓存到 Redis，避免在
chunk循环里反复查库 - 前端发起导出请求后，后端返回一个
task_id；用队列或定时任务分页拉取、生成临时文件；全部完成后再用ziparchive或xlswriter合并为单个文件 - 不要在导出接口里做
count(*)，用户不需要知道“共导出多少条”，只需提示“正在生成，请稍候”
最容易被忽略的一点：游标分页的 WHERE 条件字段必须是数据库索引字段，且不能允许 NULL；否则 MySQL 会退化成全表扫描，性能反而更差。上线前务必用 EXPLAIN 看执行计划。
