PHP大数据统计内存溢出主因是全量加载数据，应优先用MySQL聚合函数；必须PHP处理时需禁用缓冲、游标分页、及时unset释放内存。
PHP 大量数据统计时 memory_limit 被突破怎么办
直接结论：不是数据“太大”，而是你一次性把全部记录 SELECT * 加载进 PHP 数组了。MySQL 查 10 万行，每行平均 2KB，光结果集就占 200MB 内存——PHP 默认 memory_limit 通常才 128M，必然 Fatal error: Allowed memory size exhausted。
核心思路是「不加载，只计数；不缓存，只流式处理」：
- 统计类需求（求和、计数、分组聚合）优先交给 MySQL 自身的
SUM()、COUNT()、GROUP BY，结果只有几行，内存几乎不增加 - 真要 PHP 端处理（比如需调用外部 API 或复杂逻辑），必须用游标式分批：
WHERE id > ? ORDER BY id LIMIT ?，每次只取 500–2000 行，处理完立刻unset($rows) - 禁用
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY（默认开启），否则即使你用fetch()逐行读，PDO 仍会把整张结果集缓存在内存里
用 PDO::FETCH_ASSOC + 游标分页防溢出的实际写法
别用 OFFSET 分页（LIMIT 10000, 1000），大数据量下性能崩盘且无法解决内存问题。正确姿势是基于主键/时间戳游标：
$pdo = new PDO($dsn, $user, $pass, [
PDO::ATTR_EMULATE_PREPARES => false,
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false, // 关键！
]);
$lastId = 0;
$batchSize = 1000;
while (true) {
$stmt = $pdo->prepare("SELECT id, user_id, amount FROM orders
WHERE id > ? AND created_at >= '2024-01-01'
ORDER BY id LIMIT ?");
$stmt->execute([$lastId, $batchSize]);
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
if (empty($rows)) break;
foreach ($rows as $row) {
// 做你的统计逻辑，例如：
$total += $row['amount'];
$userCounts[$row['user_id']] = ($userCounts[$row['user_id']] ?? 0) + 1;
}
$lastId = end($rows)['id']; // 更新游标
unset($rows); // 立刻释放内存
}
注意：unset($rows) 不是心理安慰——它让 PHP 的 GC 能及时回收这批数组占用的内存，否则下次循环前旧数据还在。
立即学习“PHP免费学习笔记（深入）”；
生成图表前的数据预处理：别在 PHP 里拼大数组
常见错误：从数据库查出 5 万条订单，再用 foreach 构建一个含日期、销售额、订单数的二维数组，最后喂给 Chart.js。这个中间数组就是内存杀手。
更轻量的做法：
- 用 SQL 直接聚合好再查：
SELECT DATE(created_at) AS day, SUM(amount) AS total, COUNT(*) AS cnt FROM orders GROUP BY day ORDER BY day—— 返回几百行，不是几万行 - 如果前端图表需要实时交互（如按小时切片），后端只提供「聚合接口」，参数是
start_time/end_time，每次只查对应区间，不缓存历史全量 - 避免在 PHP 中做
array_merge()、array_map()套娃操作处理大数据集；能用 SQL 的COALESCE、CASE WHEN就别用 PHP 判断
容易被忽略的隐性内存消耗点
你以为清空了 $rows 就安全了？这些地方照样吃内存：
- 日志：
error_log(print_r($hugeArray, true))——print_r本身就会复制并格式化整个结构，可能比原数组还占内存 - 调试工具：Xdebug 开启时，
var_dump()或断点停留会保留变量引用，导致 GC 无法回收 - 对象未销毁：如果你在循环里 new 了某个统计类实例但没
unset()，它的属性（尤其是数组）会持续累积 - 连接未关闭：长时间运行的脚本若反复
new PDO却不unset($pdo)，底层连接资源可能泄漏
最稳妥的底线：每个批次处理完，显式 unset() 所有该批次产生的大变量，并确认没有意外的闭包引用或全局数组追加。
