PHP PDO fetchAll 内存暴涨怎么办：从全量数组到逐行读取的排查与改造

有个后台导出接口在测试环境跑着一切正常，上线到生产后刚跑60秒就直接抛出内存耗尽报错。对应的SQL执行速度并不慢，瓶颈出在PHP把全部查询结果一次性往数组里塞的步骤：单条订单明细就有几十个字段，十几万行数据直接被 PDOStatement::fetchAll() 全部加载进内存，后续还要拼CSV、做字段格式转换，内存峰值很快就越过 memory_limit。

内存突然冲高：先排查变量里是不是已经存下了一整个结果集

排查问题的时候别只盯着数据库监控指标。把报错点前后的 memory_get_usage(true) 和 memory_get_peak_usage(true) 数值记录下来，同时统计查询实际返回的总数据行数。如果内存峰值刚好出现在 fetchAll() 执行的位置后面，基本就可以把问题范围缩小到“全量结果被直接转为PHP数组”，不用再无意义排查连接池或者索引异常。

$statement = $pdo->query(
    'SELECT id, user_id, amount, created_at FROM order_logs ORDER BY id'
);

$before = memory_get_usage(true);
$rows = $statement->fetchAll(PDO::FETCH_ASSOC);
$after = memory_get_usage(true);

error_log('rows=' . count($rows));
error_log('delta=' . ($after - $before));

这种写法在后台管理页、少量配置数据读取，以及确实需要随机访问几十行结果的场景下完全没问题。它的行为非常明确，就是把剩下的所有行全部塞进数组。一旦行数不受业务控制，后续的 array_map()、JSON编码或者组装导出行的操作，还会继续复制数据进一步拉高内存占用。

先做最小判断：列表页、导出、批处理不能共用同一种取数逻辑

很多人写代码只把“能查到数据”当成唯一标准，很容易踩坑。列表页只需要当前页的少量数据，导出需要全量扫描但不需要把所有行同时放在内存里，离线任务需要按批次更新。三种场景的需求完全不一样，对应的最简实现逻辑也不同。

导出场景最简改造：逐行fetch之后立刻写出到文件

导出逻辑一般不需要在PHP里回头读取之前处理过的几千行数据。让数据库返回查询结果，循环每次只拿一行、转换一行、写入一行，内存占用基本就和单行数据大小持平，不会跟着总结果集体积同步上涨。下面给出的是静态SQL示例，带用户传入筛选条件的场景还是要走预处理和参数绑定逻辑。

$statement = $pdo->query(
    'SELECT id, user_id, amount, created_at FROM order_logs ORDER BY id'
);

$targetPath = '/var/tmp/order_logs.csv';
$output = fopen($targetPath, 'wb');
fputcsv($output, ['id', 'user_id', 'amount', 'created_at']);

while ($row = $statement->fetch(PDO::FETCH_ASSOC)) {
    fputcsv($output, [
        $row['id'],
        $row['user_id'],
        $row['amount'],
        $row['created_at'],
    ]);
}

$statement->closeCursor();
fclose($output);

这里有两个可以直接验证的点：循环中不要把 $row 追加到新创建的全量数组里，导出完成之后再看内存峰值，不会再跟着总行数线性增长。closeCursor() 适合后续还要在同一个连接上执行其他语句、当前数据库驱动对未读取完的结果有限制的场景使用。

只需要展示单页的场景：先在SQL层把结果集缩小

不少内存问题根本不是循环逻辑导致的，而是列表页默认没有加数量限制，直接查询了全量历史数据。这种情况只在PHP层补 LIMIT 做切片是不够的，排序字段也要保证稳定，最好和筛选条件一起走到对应索引，不然表面上PHP内存降了，数据库侧还是会给大量无用行做排序拖慢整体速度。

$pageSize = 100;
$lastId = 0;

$sql = 'SELECT id, user_id, amount, created_at
        FROM order_logs
        WHERE id > :last_id
        ORDER BY id
        LIMIT ' . $pageSize;

// 参数绑定与循环游标应由项目的数据访问层完成

这种按自增主键推进的分页逻辑常用于离线数据扫描，不需要做深度OFFSET，重跑任务的时候也能从最后处理完的ID位置继续执行。如果业务需要按更新时间扫描数据，还要处理同一时间戳的多条数据和并发新增的边界情况，不要直接照搬示例代码的骨架。

换成逐行读取之后还是跑慢：先排查有没有在循环里又把数据存回数组

把 fetchAll() 替换成 fetch() 之后，还是有开发者在循环里写 $result[] = transform($row)。这种操作只是把数据积压的位置从PDO返回值挪到了自己定义的业务数组里，根本没起到降内存的作用。导出场景直接往输出流写数据，批量写入任务按批次提交，统计类任务只保留累加变量，才算真正减少了常驻内存的数据量。

另一个容易被忽略的点是查询的字段选择。直接写SELECT * 也就是 SELECT * 会把不需要的大字段也一并查出来，日志正文、富文本内容、原始JSON字段在十几万行的量级下，会直接打破“单行数据很小”的判断。先列出来实际需要用到的字段，再谈读取方式的优化。

异常与资源清理：中途任务失败的时候，要留下可以断点续跑的位置

长耗时任务不能只追求低内存占用。循环执行过程中抛出异常的时候，至少要记录下最后一条处理成功的主键或者对应的时间窗口，下次运行从这个检查点继续执行，不用重新扫描整张表。对外提供的导出接口要在开始返回响应之前完成权限校验和参数合法性判断，已经开始输出内容之后再抛出HTML错误页面，用户最后拿到的只会是损坏的半截文件。

如果查询会长时间占用数据库连接，要给任务设置明确的时间窗口和最大处理行数上限。不要第一反应就去调大 memory_limit 的数值，这种操作只会把故障从“快速报错”变成“长时间占用大量资源拖垮整个服务”。

改造完成之后怎么验证：看内存峰值曲线，不要只跑一次成功就完事

用和生产环境体量接近的测试数据跑两次，一次保留旧的全量数组读取版本，一次用改造后的逐行或者分批读取版本。对比 memory_get_peak_usage(true)、总耗时、写入成功的行数和异常出现的次数。理想的改造结果不是某个固定的内存数值，而是数据量增长的时候，内存峰值不会跟着全量结果集同步线性上涨。

如果逐行读取的版本速度比全量读取慢，也不要马上就切回原来的全量逻辑。先排查瓶颈出在数据库传输、单行列转换还是输出目标的写入速度，必要的时候调整批次大小，或者把聚合逻辑下推到SQL层执行。内存占用和整体吞吐要一起测试验证，才能找到适合业务的平衡点。

相关问题

fetchAll() 在什么场景下依然适合使用？

结果集有明确的数量上限、后续逻辑确实需要多次随机访问数据，或者读取少量字典配置数据的时候完全可以使用。核心判断标准从来不是函数叫什么名字，而是调用这个方法的位置，能不能明确预知最多返回多少条数据。

逐行fetch会不会每次都重新发起数据库查询？

不会。它是在同一个已经执行完成的结果集上读取下一行，实际的网络传输和驱动层缓冲行为，和数据库驱动类型、连接方式、查询本身的逻辑都有关系，最终效果还是要用真实的业务数据做压测验证。

为什么列表页不能一直靠OFFSET深翻页？

页数比较小的时候OFFSET使用起来很方便，翻到很深的页码之后，数据库需要跳过大量无关记录才能拿到目标数据。全量扫描场景下，用稳定自增键推进的方式更容易控制性能，也方便实现断点续跑。

closeCursor() 是不是每次读取完数据都必须调用？

不是所有驱动、所有请求场景都必须调用，但是后续要在同一个数据库连接上执行其他SQL语句，前一个结果集还没有被完全读取完的时候，调用这个方法能帮数据库连接释放游标资源。用项目实际使用的驱动做一次集成验证，得到的结论最可靠。

把数据量当成接口的设计参数，不要等出了问题才临时补救

fetchAll() 本身不是错误用法，它只是非常直白地把“所有结果会全部转为PHP数组”这个选择暴露出来。给列表、导出、批处理不同场景分别设置对应的结果集边界，改造完成之后用内存峰值指标做验证，内存耗尽就不会变成上线之后才偶然触发的线上故障。