是，fetchAll会将整个结果集一次性加载到内存。它不区分数据量大小，直接把所有行从MySQL缓冲区拷贝至PHP用户空间数组，导致内存消耗达实际数据3–5倍，远超fetch()逐行处理的内存占用。
fetchAll 会把整个结果集一次性塞进内存
PDO::fetchAll 不是逐行取数据，而是驱动层把所有行从 MySQL 的网络缓冲区、协议解析器、PDO 内部 result set 结构一路拷贝到 PHP 用户空间的数组里。哪怕只有 1 万行，每行平均 2 KB，光数据就占 20 MB；再加上键名重复存储（['id' => 1, 'name' => 'a'] 每行都存一次字符串 'id'）、zval 开销、哈希表扩容碎片，实际内存消耗常达 3–5 倍。
- 它不关心你后续是否只用前 10 行——只要执行了，整张表（或整个结果集）就已落地内存
- 即使 SQL 加了
LIMIT 100，只要没加WHERE或索引支持，MySQL 仍可能扫描百万行再裁剪，PDO 不参与这个过程，只管收包 - 返回的是完整二维数组，无法用
yield流式消费，GC 也无从介入中间过程
和 fetch() 循环比，内存峰值差一个数量级
基准测试中，查 5 万行用户数据：PDO::fetchAll 启动后内存立刻跳升 120 MB；而 while ($row = $stmt->fetch()) 整个循环过程内存波动始终控制在 8–12 MB 区间——因为每次只构造一个 $row 数组，上一轮的 zval 在下一轮开始前大概率已被回收。
-
fetch()返回的是新分配的数组，但生命周期极短；fetchAll()返回的是一个含数万个子数组的大数组，根引用一直存在直到函数返回或变量被 unset - 如果在循环里对
fetchAll()结果又做array_map或json_encode，内存会再翻倍——这些操作都在已有大数组基础上叠加新结构 - CLI 脚本中尤其危险：Web 请求结束自动清场，CLI 却长期持有所有行，
gc_collect_cycles()对这种线性大数组基本无效
错误日志里 “Allowed memory size exhausted” 往往就卡在这行
看到 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 2097152 bytes)，先别急着改 memory_limit。用 memory_get_usage(true) 在 fetchAll() 前后各打一次点：
echo 'before: ' . memory_get_usage(true) . "\n"; $result = $stmt->fetchAll(); echo 'after: ' . memory_get_usage(true) . "\n";
- 如果差值稳定在 50+ MB，基本可锁定是
fetchAll()导致——不是代码逻辑错，是加载模式错 - 注意检查是否误写了
$stmt->fetchAll()->fetch()这类无效链式调用，会导致对象残留 + 内存不释放 - 有些 ORM 封装层默认走
fetchAll（比如旧版 Laravel 的get()），需看文档确认底层行为
替代方案不是“换函数”，而是换数据消费模型
直接换成 fetch() 循环只是第一步。真正要解决的，是“为什么需要全量加载”。很多场景其实只需要流式处理、分块导出、或前端分页。
立即学习“PHP免费学习笔记（深入）”；
- 导出 CSV？用
fputcsv(fopen("php://output"), $row)+fflush()，内存恒定在 KB 级 - 要做搜索联想？加
LIMIT 20+ 全文索引，别查出全部再array_filter - 必须聚合统计？让 MySQL 做
GROUP BY和COUNT，PHP 只收几行结果 - 真要遍历全部且后续多次访问？考虑
yield封装成生成器，或用PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false让 MySQL 不缓存结果（配合fetch()）
最常被忽略的一点：fetchAll() 看似方便，实则是把数据库压力转嫁给了 PHP 内存。而数据库本来就是为高效筛选和聚合设计的——把计算留在 SQL 层，永远比拉回 PHP 做更快、更省内存。
