应使用流式读取避免OOM：调用getBlob()获取sql::Blob，再用getBinaryStream()获得std::istream分块读取，需手动释放内存并结合length()与gcount()校验长度，同时设置net_read_timeout和定期ping保活连接。
MySQL C++ Connector 查询 BLOB 时内存暴涨怎么办
直接用 sql::ResultSet::getBlob() 或 getString() 读取大 BLOB（比如 >10MB）会把整个二进制内容一次性加载进内存，极易触发 OOM。这不是驱动 bug，而是默认行为——它把 BLOB 当作普通字段处理。
真正可行的路径是绕过“全量加载”，改用流式读取：
- 调用
rs->getBlob(idx)获取sql::Blob*指针，但**不调用sql::Blob::getBytes()** - 用
sql::Blob::getBinaryStream()得到std::istream*，然后分块读取（例如每次 64KB） - 务必在读完后手动
delete返回的sql::Blob*和std::istream*，Connector 不自动释放这些堆对象
为什么 std::istream* 读取后数据变乱码或截断
常见原因是没检查流状态或忽略 BLOB 实际长度。MySQL Connector 的 std::istream* 不自带长度信息，gcount() 返回上次读取字节数，但流可能提前 EOF（比如网络中断、服务端主动断连）。
安全做法是结合 sql::Blob::length() 做双重校验：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 先调
blob->length()获取服务端声明的 BLOB 长度（注意：该值可能不准，尤其 MyISAM 表） - 循环读取时，每次用
is->read(buf, buf_size)，再用is->gcount()判断本次实际读了多少 - 若
gcount() == 0且总读取字节数
mysqlcppconn8 和 mysql-connector-c++ 1.1 的流行为差异
新版 mysqlcppconn8（8.0+）返回的 std::istream* 是只读、不可 seek 的管道流；老版 mysql-connector-c++ 1.1（基于 MySQL C API）返回的流支持 seekg()，但实际 seek 会失败并置流为 failbit——这点文档完全没提。
所以无论哪个版本，都应按顺序读取，别依赖随机访问：
- 不要对流调用
seekg()或tellg() - 避免用
std::stringstream中转——它会把所有数据缓存在内存里，又回到原点 - 写入文件时直接用
std::ofstream的write()，别经过 string/vector 中转
如何避免查询期间连接被服务端 kill
大 BLOB 传输耗时长，MySQL 默认 wait_timeout=28800（8 小时），但很多生产环境设成 300 秒。如果流读取时间超限，服务端会关闭连接，后续 is->read() 返回 0 字节且 is->fail() 为 true。
预防手段只有两个硬措施：
- 查询前执行
SET SESSION net_read_timeout = 3600（单位秒），确保足够读完最大 BLOB - 在读取循环中每读 1MB 就调一次
con->ping()，维持连接活跃（注意：频繁 ping 有开销，按需启用）
没有“自动重连流”的机制，一旦中断只能重发整个查询——BLOB 不支持断点续传。
