优先改数据获取方式为流式处理：用 fetch() 或游标遍历，PDO 关缓冲、MySQLi 用 use_result()，配合 fputcsv 逐行写入并及时 unset，避免全量加载和字符串拼接。
PHP 导出大数据时 memory_limit 被打穿怎么办
直接调高 memory_limit 不是万能解法，尤其在 cli 环境下，它可能掩盖真正瓶颈——比如一次性读完全部数据再处理。导出逻辑若用 select * 加 fetchall()，几万行就容易 oom，和配置值关系不大。
- 优先改数据获取方式：用
fetch()或游标式遍历（如 PDO 的PDO::FETCH_ORI_NEXT），每次只拿一行或一批（fetchMany(1000)） - CLI 脚本必须显式设置内存限制：
ini_set('memory_limit', '512M');，不能只依赖 php.ini，因为 CLI 和 Web SAPI 的配置常不一致 - 确认是否真缺内存：用
memory_get_usage(true)在循环中打点，看增长拐点在哪——是数据库结果集膨胀？还是导出中间数组没释放？
用 fputcsv 写文件却卡住或内存不降
fputcsv 本身不占内存，但如果你把所有 CSV 行先拼成一个大字符串再写入，就等于又造了个内存炸弹。常见于“收集所有数据 → implode("\n", $rows) → file_put_contents”这种写法。
- 必须流式写入：打开文件句柄后，在循环里逐行调用
fputcsv($fp, $row)，写完立刻unset($row) - 避免隐式复制：传给
fputcsv的数组别带冗余字段，导出前用array_intersect_key精确选列，减少每行内存占用 - 注意输出缓冲：CLI 下默认无输出缓冲，但若误启了
ob_start()，会导致内容滞留在内存里不落地
MySQL 查询本身就把 PHP 进程拖垮了
不是 PHP 内存不够，是 MySQL 返回的结果集太大，PDO/MySQLi 默认会把整张结果集缓存在 PHP 内存里。哪怕你只 fetch 一行，底层也早把全部数据拉过来了。
- PDO 必须关预取：
$pdo->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, false);，再配合query()+fetch()才真正流式 - MySQLi 要用
mysqli_use_result()替代mysqli_store_result()（后者是默认行为，等同于全量加载） - 加
LIMIT和合理WHERE条件比调内存更治本；导出前先SELECT COUNT(*)预估量级，超阈值（如 50 万行）就切分导出
导出脚本跑着跑着被系统 kill 掉了
Linux 的 OOM Killer 会盯上内存暴涨的进程，即使 PHP 的 memory_limit 没超，系统总内存耗尽也会直接干掉它。这时候 dmesg | tail 里能看到 “Out of memory: Kill process” 日志。
- 用
top或ps aux --sort=-%mem实时观察 PHP 进程 RSS 内存，别只信memory_get_usage() - 导出过程中主动释放资源：查完就
$stmt->closeCursor()，大对象及时unset，关闭不用的 DB 连接 - 考虑改用生成器（
yield）封装数据流，天然规避中间数组堆积，但要注意 Generator 本身不释放 DB 句柄，得手动管理
最麻烦的其实是混合场景：MySQL 流式查询 + PHP Generator + CSV 流写入，三者生命周期要对齐，不然连接没关、文件没 close、yield 没遍历完，就等着被 OOM Killer 点名。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
