别再用 fetchAll 扛所有查询了：PDO 游标思维才是内存救星

线上定时任务跑了一下，PHP 进程直接 OOM 退出。排查半天，罪魁祸首竟然是几行看似人畜无害的 $stmt->fetchAll()。数据库里躺着三十万条业务明细，全塞进一个二维数组里，服务器内存再大也兜不住。写过几年 PHP 的人都会碰到这种场面：把 PDO 当成简单的“数据搬运工”，却忘了它底层其实提供了更精细的控制杠杆。搞懂 fetch 和 fetchAll 的边界，能提前拦下大半性能事故。

这两者的核心差异不在语法糖，而在数据加载策略。fetchAll() 就像等快递全拆完才签收，驱动会把整张结果集从 MySQL 拉到 PHP 内存里，构建好完整的数组结构后才交给你。查询期间网络通道一直被占用，适用场景很明确：数据量可控的分页列表、静态配置表读取、或者需要整体做二次加工的数据源。

换成 fetch()，逻辑就彻底变了。它是一次只取一行的流式读取。每执行一次，底层游标向后挪动一格，吐出一条记录给你处理，当前这一行出作用域后内存立刻回收。面对按月导出的 CSV、或者逐条落盘清洗的日志表，这种按需索取的姿势能把峰值内存稳稳压在十几 KB。配合 while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) { /* 逐行计算/写入/转发 */ } 的写法，是处理海量数据的标准解法。

实际落地时，很多人会纠结数据结构怎么定型。现代 PHP 工程里，建议用对象接住业务载荷。初始化语句对象后调用 $stmt->setFetchMode(PDO::FETCH_OBJ)，之后的每一次 fetch() 都会直接吐出 stdClass 实例，告别满屏 $row['user_id'] 的下标硬编码。如果遇到需要按状态分组的复杂聚合，可以用 fetchAll(PDO::FETCH_GROUP|PDO::FETCH_ASSOC) 一步到位拿到分组字典，后续交给 array_map 做格式化，比在循环里手写判断清晰得多。

别以为加了游标就能高枕无忧。fetch() 不负责排序也不负责去重，它只是忠实地按 SQL 返回顺序喂数据。如果查询条件没命中索引，数据库全表扫描带来的 CPU 消耗反而会放大。实战中建议在连接层统一设定默认提取方式：$pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);，这样日常开发不用反复声明模式，代码阅读成本直线下降。

数据库交互从来不是“查出塞进去”那么简单。认清 fetchAll 的批量囤货属性与 fetch 的流水账特性，是在内存预算和开发效率之间做取舍的基本功。下次再碰到大表查询，先停一秒想清楚：是需要一次性拉齐开干，还是边流边算？切换加载节奏，系统稳定性自然会给你正向反馈。