必须在查询结果集极大、内存受限且只需流式消费数据时设为false：此时PHP逐行拉取，内存恒定KB级，但禁用fetchAll、rowCount等，且要求mysqlnd驱动支持。
什么时候必须用 PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = false
当查询结果集极大（比如上百万行）、内存受限，且业务只要流式消费数据（如导出 CSV、实时推送、ETL 清洗），不需随机访问或多次遍历结果时，才需要关缓冲。
PHP 默认开启结果集缓冲（PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = true），意味着 execute() 后 MySQL 就把全部结果发给 PHP，存在两处风险：一是 PHP 进程内存暴涨，二是 MySQL 连接被长时间占用无法释放。关缓冲后，PHP 只在每次 fetch() 时向 MySQL 拉一行（或按网络包大小分批），连接能更早释放，内存恒定在 KB 级。
- 典型场景：后台跑订单导出脚本，查 500 万条记录生成 CSV 文件
- 典型场景：微服务间通过 SSE 推送实时日志流，每行日志独立处理并立即返回 HTTP chunk
- 典型场景：数据迁移工具从旧库读取再写入新库，中间不做聚合或排序
关缓冲后 fetchAll() 和游标操作会直接失败
关缓冲后，PDOStatement 不再支持 fetchAll()、fetchColumn()（除首行外）、rowCount()（返回 -1），也无法倒序 fetch() 或重复调用 fetch() 回到上一行。所有数据只能单向、顺序、一次消费。
如果你的代码里有类似 $rows = $stmt->fetchAll(); foreach ($rows as $r) { ... } 或 while ($row = $stmt->fetch()) { $stmt->fetch(); // 想跳过下一行 }，关缓冲后会抛 PDOException 或静默返回 false。
立即学习“PHP免费学习笔记（深入）”；
- 必须改用
while ($row = $stmt->fetch()) { /* 处理单行 */ }结构 - 不能依赖
count($stmt->fetchAll())做分页计数，得提前用SELECT COUNT(*)单独查 - 如果前端需要“上一页/下一页”，关缓冲就不适用——得换成分页查询或启用游标分页（
WHERE id > ? LIMIT N）
MySQL 驱动必须是 mysqlnd，libmysql 不支持关缓冲
PHP 8.3 默认启用 mysqlnd，但某些定制环境（如老旧 Docker 镜像、手动编译 PHP 时未启用 --with-mysql=mysqlnd）仍可能用 libmysql。后者完全忽略 PDO::MYSQL_ATTR_USE_BUFFERED_QUERY 设置，无论设 true 还是 false，行为都等同于 true。
验证方式：访问 /info.php 页面，搜索 “mysqlnd”；若没看到版本号，说明驱动不对，关缓冲配置无效，且后续可能因内存耗尽被 OOM killer 杀掉进程。
- 修复方法：重装 PHP 并确保编译参数含
--with-mysql=mysqlnd，或改用官方php:8.3-cli镜像 - 临时绕过：在 DSN 中加
;options=1024（即MYSQLI_OPT_CONNECT_TIMEOUT的值）毫无意义，libmysql 不识别该 flag - 注意：PDO 构造时传第 4 个
$options数组，必须严格只含 4 个元素；PHP 8.3 下多传一个 null 会直接TypeError
关缓冲后事务和连接生命周期要手动对齐
关缓冲时，MySQL 连接在最后一行 fetch() 完成后不会自动释放，而是等到 PDOStatement 对象被销毁（如变量置为 null 或超出作用域）。如果在长循环中忘了清理，会导致连接池快速耗尽。
更隐蔽的问题是：若在关缓冲查询期间执行了 INSERT/UPDATE，而事务未显式 commit() 或 rollback()，连接会一直持有锁，阻塞其他请求。
- 务必在
while循环结束后，显式置空语句对象：$stmt = null; - 避免在同一个 PDO 连接上混用关缓冲查询和写操作；写操作应另起连接或确保查询彻底结束
- 不要依赖脚本结束时 PHP 自动回收——CLI 脚本可能运行数小时，连接泄漏风险极高
真正需要关缓冲的场景极少，多数所谓“大数据量”问题其实出在 SQL 本身（缺索引、全表扫描）或 PHP 层逻辑（如把整张表 load 到内存再 filter）。先确认 EXPLAIN 输出是否走了索引，再决定要不要动这个开关。
