SaaS 大数据导出为什么容易拖垮服务器？PHP 应该怎样分批读取

SaaS系统中的数据导出，看起来只是把数据库里的记录转换成CSV文件，真正执行起来却可能同时消耗数据库、PHP进程、磁盘IO、网络带宽和连接池资源。当用户要求导出几十万、几百万甚至更大规模的数据时，如果仍然采用“一次SQL查询全部数据，然后PHP一次性处理”的方式，系统很容易出现内存暴涨、请求超时、数据库负载升高以及PHP-FPM工作进程被长期占用等问题。

大数据导出的第一个风险是内存，而不是SQL语句本身。PHP如果使用fetchAll()一次性读取几十万甚至上百万行，数据库返回的数据会进入PHP进程，同时每一行又会被转换成PHP数组。PHP数组的实际内存开销远远高于数据库中一条记录的原始字节数，因此不能用“每行100字节，100万行就是100MB”这样的简单计算估算PHP内存。实际占用可能高得多，尤其是字段较多、字符串较长或者存在大量关联数据时。

因此，导出程序应该把数据库读取、数据转换和文件写入限制在一个较小的批次内。常见做法是使用Keyset Pagination，也就是键集分页，而不是不断增加OFFSET。

例如按照唯一递增的id导出，可以使用：

$lastId = 0;
$batchSize = 1000;

while (true) {
$stmt = $pdo->prepare("
SELECT id, name, created_at
FROM users
WHERE id > ?
ORDER BY id ASC
LIMIT $batchSize
");

$stmt->execute([$lastId]);

$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);

if (!$rows) {
break;
}

foreach ($rows as $row) {
// 写入CSV
}

$lastId = $rows[count($rows) - 1]['id'];
}

这里的核心不是“使用MySQL游标”，而是每次记录上一批数据的最后一个排序键，再从这个位置继续读取。对于简单的单表递增ID导出，这种方式通常比LIMIT 500000, 1000之类的深度OFFSET分页更加适合大数据量场景。

当然，id并不是所有导出的最佳游标。如果业务要求按照created_at排序，就不能只保存时间戳，因为多个记录可能拥有完全相同的时间。更可靠的方式是使用created_at + id这样的复合排序键：

SELECT id, created_at, name
FROM orders
WHERE tenant_id = ?
AND (
created_at > ?
OR (created_at = ? AND id > ?)
)
ORDER BY created_at ASC, id ASC
LIMIT 1000;

相应的索引通常应该考虑：

(tenant_id, created_at, id)

这对于SaaS系统尤其重要，因为租户隔离条件通常应该成为查询和索引设计的一部分。实际索引仍然需要根据WHERE、ORDER BY、选择性和执行计划验证，不能机械地给每个导出字段建立索引。

第二个关键问题是不要把整个导出文件先放进PHP内存。生成CSV时，可以直接打开文件，然后一批一批查询、一行一行写入：

$fp = fopen('/path/to/export.csv', 'w');

fputcsv($fp, ['id', 'name', 'created_at']);

$lastId = 0;
$batchSize = 1000;

while (true) {
$stmt = $pdo->prepare("
SELECT id, name, created_at
FROM users
WHERE id > ?
ORDER BY id ASC
LIMIT $batchSize
");

$stmt->execute([$lastId]);

$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);

if (!$rows) {
break;
}

foreach ($rows as $row) {
fputcsv($fp, [
$row['id'],
$row['name'],
$row['created_at']
]);
}

$lastId = $rows[count($rows) - 1]['id'];

unset($rows);
}

fclose($fp);

这里虽然仍然使用了fetchAll()，但它只保存当前批次，因此内存规模基本与批次大小相关，而不是与整个导出任务的数据总量一起增长。对于更大的导出任务，还可以进一步采用PDO驱动支持的逐行读取方式，减少客户端一次性保存一批结果的必要性。

数据库方面也需要注意一个常见误区：SELECT ... LIMIT 1000000不会因为查询了100万行就自动“锁住整张表”。对于InnoDB普通一致性读取，单纯的SELECT通常不会像UPDATE或SELECT ... FOR UPDATE那样产生行锁。真正的问题是查询可能扫描和返回大量数据，消耗CPU、磁盘IO、Buffer Pool以及数据库连接时间，从而与正常业务争抢资源。

OFFSET分页则是另外一个性能问题。当查询变成：

LIMIT 900000, 1000

数据库往往需要找到并跳过前面的大量记录，然后才能返回后面的1000条。随着OFFSET越来越深，查询成本可能明显增加。键集分页通过索引直接从上一次的位置继续向前读取，因此特别适合“下一页”“继续导出”这种顺序访问场景。

导出查询还应该避免没有必要的SELECT *。导出程序需要哪些字段，就明确选择哪些字段。这样不仅减少数据库读取和网络传输，也降低PHP解析数据以及生成文件的成本。如果查询涉及多个JOIN，更应该通过EXPLAIN或EXPLAIN ANALYZE检查实际执行计划，而不是看到JOIN就认为必须拆掉，或者看到子查询就认为一定更快。

覆盖索引也不能成为大数据导出的万能答案。如果导出只需要少数几个字段，一个设计合理的覆盖索引确实可能减少回表；但如果导出几十个字段，把所有字段都塞进索引会增加索引体积和写入成本。对于经常运行的导出任务，应该根据实际查询计划、扫描行数、IO和业务写入压力进行权衡。

当导出达到几十万甚至百万级以后，另一个重要问题是不要让用户的HTTP请求一直挂在那里。一个大型导出如果需要几分钟甚至几十分钟完成，就不应该依赖普通Web请求从开始一直运行到结束。更合理的架构是用户创建导出任务，系统返回任务ID，然后由后台Worker负责生成文件。

任务队列可以使用Redis、RabbitMQ或其他消息系统，但消息队列只是调度工具，并不会自动解决数据库和PHP的性能问题。Worker仍然需要采用批量读取、流式写入、错误重试和任务状态管理。

典型流程可以变成：

用户提交导出
↓
创建export_job
↓
消息队列
↓
PHP Worker
↓
分批读取MySQL
↓
流式生成CSV
↓
上传对象存储
↓
任务完成
↓
用户获得下载地址

这样做的另一个好处，是生成文件和用户下载文件可以彻底分开。PHP Worker负责生产文件，Nginx、对象存储或CDN负责向用户提供下载，避免一个PHP-FPM进程同时承担数据库查询、CSV生成和长时间HTTP传输。

对于非常大的导出文件，对象存储通常比把文件长期放在PHP服务器本地更加适合。文件生成完成后，可以保存到对象存储，再通过具有过期时间的下载地址提供给用户。对于敏感数据，还需要加入权限验证、下载过期时间、审计日志以及文件删除策略。

限流也应该放在正确的位置。Nginx的limit_rate可以控制下载速度，但它解决的是网络传输压力，并不能降低生成文件时的数据库负载。如果导出任务本身已经把MySQL打满，仅仅把下载速度限制到100KB/s并不能解决数据库问题。

真正有效的限流通常包括任务级别和用户级别的控制。例如同一个租户同时只允许运行一个大型导出任务，整个系统限制并发Worker数量，并且对单次导出的最大数据量设置合理限制。对于特别大的任务，还可以按照时间范围拆分，或者要求用户异步等待生成。

数据库读副本可以用于隔离部分查询压力，但也不能简单理解为“所有导出都应该去只读副本”。复制存在延迟，因此刚刚写入的数据可能暂时还没有出现在副本中；如果导出要求强一致或者必须包含刚刚提交的数据，就需要重新考虑数据来源和一致性策略。

此外，大型导出最好不要长时间持有一个数据库事务。事务持续时间过长可能增加资源占用，并影响数据库内部的历史版本清理等机制。普通导出通常可以采用短批次读取，而不是为了“保证一致性”把整个百万级导出包在一个超长事务里。

如果业务要求导出的数据在整个任务期间保持一个稳定快照，那么问题就从普通分页升级成了数据一致性设计。例如可以记录导出任务创建时的时间边界：

WHERE created_at < :export_cutoff

然后所有批次都按照这个边界读取。这样在导出过程中新增的数据不会突然进入结果集。对于更新中的数据，则需要根据业务需求进一步设计快照、版本号或数据库事务策略，不能仅靠一个last_id解决所有一致性问题。

缓存同样不能被当成大型导出的默认答案。Redis适合缓存热点、小型、重复访问的数据，但一个用户临时导出100万条订单，先把这100万条数据塞进Redis再导出来，通常只是把压力从MySQL转移到另一个系统。对于一次性的导出任务，直接批量读取并流式生成文件通常更加合理。

安全问题也不能被性能问题掩盖。SaaS导出尤其涉及租户隔离和敏感数据。每一个批次的SQL都必须继续带有tenant_id等权限边界，不能因为导出程序是后台Worker，就绕过正常的数据授权逻辑。身份证件、财务信息、联系方式等敏感字段还应该根据业务权限进行脱敏或限制导出。

因此，大数据导出的性能优化并不是单纯把LIMIT 1000000改成LIMIT 1000。真正成熟的方案通常包含几个环节：数据库使用适合排序条件的索引，读取采用键集分页，PHP只处理当前批次，文件采用流式生成，大型任务通过Worker异步执行，下载与文件生成分离，同时控制并发和资源使用。

最终需要监控的指标也不只是PHP内存。数据库侧应该观察查询耗时、扫描行数、CPU、IO、Buffer Pool以及连接数；PHP侧应该观察Worker内存、执行时间和失败率；任务系统需要记录队列长度和任务等待时间；文件服务则需要观察生成速度、文件大小和下载流量。只有把这些指标放在一起，才能判断瓶颈究竟发生在数据库、应用层还是网络层。

SaaS的大数据导出，本质上不是一个“把数据库内容搬到CSV”的简单功能，而是一条完整的数据处理流水线。数据量小时，普通查询完全够用；数据量增长以后，关键就变成如何让每个环节只处理自己应该处理的那一部分工作。数据库负责稳定读取，PHP负责流式转换，Worker负责异步执行，对象存储负责保存文件，下载服务负责传输。把这些职责拆开之后，即使导出数据达到百万级，系统也不必让一个PHP请求和一条数据库连接从头忙到尾。