如何用 TP6.0 做千万级数据导出？Cursor 游标实战教学【大数据】

ThinkPHP 6.0 不支持 `Db::cursor()`，需用 `where` + `order` + `limit` 模拟游标分页导出千万级数据，避免内存溢出和超时；应选 `id` 作游标字段、禁用超时、刷输出缓冲、确保索引优化。

先别急着在网上搜“TP6 cursor 导出”的代码——那个 `Db::cursor()` 方法在 ThinkPHP 6.0 里压根就不存在。你没看错，官方既没暴露 PDO 游标控制权，也没实现 `cursor()`。所有声称“TP6 支持游标查询”的教程，本质上都是拿 `where('id', '>', $lastId)` 手动拼出来的。你真正需要的，是用 `where + order + limit` 模拟游标分页，来搞定千万级数据导出，同时把内存溢出和 MySQL 连接超时挡在门外。

为什么 Db::cursor() 会报错或根本找不到

ThinkPHP 6.x 的 Db 和 Model 层在设计上就没给 PDO 游标留接口。你翻翻官方文档，搜“cursor”三个字母，结果为空；去 GitHub 源码里 grep，也找不到该方法的定义。这就好比你想在自行车上装火箭引擎——框架根本没预留那个安装位。所有跑通的“cursor 导出”代码，底层全是手动游标分页：每次只查比上一页最后 id 大的那批数据，再配合 order 和 limit 做边界控制。

千万级导出必须用「游标分页」而非 chunk()

chunk() 看起来方便？实际上是个大坑。它本质上是分批 select，每一批都完整加载进 PHP 内存，而且依赖 offset——数据量越大，offset 越往后，查询越慢。假设你要导出 500 万行，chunk(1000) 会执行 5000 次 SQL，中间任意一次失败就得重头再来。更别说 paginate() 还要先跑 count()，千万级表上那个 count 本身就能把数据库卡死。

• ✅ 正确做法：用排序字段（比如 id）做游标锚点，每次只查「比上一页最后 id 更大」的新数据，永远不依赖 offset
• ❌ 错误做法：用 paginate() 或 chunk() 做全量导出——count 卡死 + 内存随批次线性增长，双杀
• ⚠️ 注意：别拿 created_at 单独当游标字段——时间戳重复会导致漏行或重复导出。优先选 id，或者组合 id + created_at

导出循环中必须带 set_time_limit(0) 和显式 ob_flush()

默认 PHP 脚本超时只有 30 秒，导出千万行数据至少得跑几分钟甚至几十分钟。不关超时，脚本中途就会断掉。同时输出缓冲区如果不主动刷，浏览器会一直在那转圈，直到全部写完才响应——用户还以为程序死了。

• set_time_limit(0) 放在循环开始前，直接把超时限制关掉
• 每处理完一批（比如 1000 行），调用 ob_flush() 和 flush() 强制把内容推到客户端
• 尽量避免用 echo 拼 CSV 字符串，改用 fputcsv($fp, $row) 写临时文件，最后 readfile() 输出，更稳也更省内存

MySQL 索引和事务配置决定成败

游标分页的性能全靠索引撑着。如果 ORDER BY id DESC + WHERE id < ? 没走索引，那就变成全表扫描——导出从“慢”直接变成“卡死”。所以必须确保排序字段有主键或二级索引；复合游标比如 (status, id) 得建联合索引。另外，事务配置是个容易踩的坑：别把 Db::startTrans() 套在整个导出循环上，那样会让 MySQL 锁住 MVCC 快照，内存占用飙升。正确做法是保持 SET SESSION autocommit = 1，避免长事务。

游标分页不是什么“高级技巧”，而是千万级导出的底线要求。最容易被忽略的恰恰是最基础的：没索引的 where + order 在小数据量时能跑通，但数据一上去就退化成全表扫描——那时候你不是在导出数据，是在给 MySQL 做压力测试。