db2_lob_read是db2专用的逐块读取lob函数，用于避免内存溢出；而pdo::attr_lob_conversion仅控制是否自动转换blob为字符串，开启易导致oom。
db2_lob_read 和 PDO::getAttribute(PDO::ATTR_LOB_CONVERSION) 不是同一类东西：前者是 DB2 专用的逐块读取函数，后者只是控制 PDO 是否自动把 BLOB 转成字符串——开它反而容易 OOM。真要防内存压力，必须绕过“一次性 fetch”模式，改用流式接口。
为什么直接 $row['blob_field'] 会崩内存
PHP 的 PDO 默认把整个 BLOB 字段当字符串加载进内存。哪怕一个 50MB 的 PDF，fetch() 一调，PHP 进程就多占 50MB；并发 10 个请求，光这一个字段就能吃掉 500MB。更糟的是，MySQL 的 max_allowed_packet 或 DB2 的 LOB 配置可能中途截断数据，但 PHP 不报错，只给你个不完整的字符串。
避免方式：
- 禁用自动转换：
$pdo->setAttribute(PDO::ATTR_LOB_CONVERSION, false) - 确认驱动支持流：MySQL 用
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = false；DB2 必须用db2_lob_read()；SQL Server 则依赖sqlsrv_get_field($stmt, $colIndex, SQLSRV_PHPTYPE_STREAM(SQLSRV_ENC_BINARY)) - 永远别对 BLOB 字段用
PDO::FETCH_ASSOC或fetchColumn()
MySQL 场景下用 stream_get_contents() 安全读取
MySQL 原生不提供分块读 API，但 PDO 可以返回资源型 stream（前提是字段类型是 BLOB 或 MEDIUMBLOB，且未启用缓冲查询）。
实操要点：
- 准备语句时加
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false（注意：这是连接属性，不是语句属性） -
execute()后立刻用bindColumn()绑定 BLOB 列到变量，类型设为PDO::PARAM_LOB - 调用
fetch()后，该变量才是可读 stream，不是字符串 - 用
fread()或stream_get_contents()分批读，比如每次 8192 字节
示例关键片段：
$pdo = new PDO($dsn, $user, $pass, [
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false
]);
$stmt = $pdo->prepare("SELECT data FROM files WHERE id = ?");
$stmt->execute([$id]);
$stmt->bindColumn('data', $lob, PDO::PARAM_LOB);
$stmt->fetch();
// 此时 $lob 是 resource，不是 string
while (!feof($lob)) {
$chunk = fread($lob, 8192);
// 处理 $chunk，比如写入文件或加密
}
DB2 必须用 db2_lob_read()，不能靠 PDO
DB2 的 PDO 驱动（ibm_db2）对 LOB 字段完全不支持流式绑定。即使你设了 PDO::PARAM_LOB，fetch() 仍会试图把整个 LOB 加载为字符串，db2_lob_read() 是唯一可控的分块入口。
注意点：
-
db2_lob_read($result, $column, $length)的$column是从 1 开始的列序号，不是字段名 - 返回
false表示已读完，不是错误；空字符串可能是中间块，需继续调用 - 每次读长度建议 ≤ 32767 字节（DB2 协议限制），太小则 syscall 开销高，太大易触发超时
- 必须在
db2_fetch_row()之后才能调用，否则返回false
典型循环结构：
$result = db2_exec($conn, "SELECT id, my_blob FROM blob_stream WHERE id = 1");
db2_fetch_row($result);
$offset = 0;
while ($chunk = db2_lob_read($result, 2, 32767)) {
file_put_contents("part_{$offset}.bin", $chunk);
$offset += strlen($chunk);
}
前端传回大 BLOB 时，别在 PHP 层 base64 编码
有人想“保险起见”，把 BLOB 读出来再 base64_encode() 发给前端，这会让内存占用翻 1.33 倍（base64 膨胀率），还增加 CPU 开销。真正需要传输时，应该：
- 后端直接输出原始二进制（
header('Content-Type: application/octet-stream')+echo $chunk） - 前端用
fetch()+response.arrayBuffer()接收，再转Blob或File - 若必须走 JSON，用
json_encode(['data' => bin2hex($chunk)])比 base64 更省内存（hex 是 2x，base64 是 1.33x 但编码慢）
最易被忽略的一点：DB2 的 db2_lob_read() 返回的是原始字节，没有字符集转换；而 MySQL 的 stream 在 latin1 连接下可能被误解为文本——务必确认连接字符集是 binary 或显式设置 SET NAMES binary。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
