MySQL BLOB字段无法通过SELECT直接导出为文件，必须由应用层读取后构造HTTP响应头并原样输出二进制流，关键在于禁用模拟预处理、清空输出缓冲、设置正确Content-Type/Length/Disposition头。
MySQL 查询结果里怎么直接导出 BLOB 字段为文件
不能靠 select 语句直接“下载”，blob 是二进制数据，sql 客户端（如 mysql cli、phpmyadmin）默认只显示长度或十六进制摘要，不触发浏览器下载行为。真正能“导出为文件”的动作必须由应用层（php/python/node.js 等）或客户端工具显式发起。
常见错误现象：SELECT file_data FROM docs WHERE id = 1 在 phpMyAdmin 里只看到 (BLOB) 或一长串 0x47494638...，点保存也没用；用命令行执行也只会把二进制乱码打到终端，甚至卡死。
- 使用场景：后台管理页需要提供“点击下载原始附件”按钮，对应数据库某条记录的
contentBLOB 字段 - 关键动作不是“查”，而是“查出来 → 构造 HTTP 响应头 → 输出原始字节流”
- 不要试图在 SQL 层做文件落地（比如用
SELECT ... INTO DUMPFILE），那写的是服务器本地磁盘，和用户下载无关
PHP 中用 PDO 读取 BLOB 并强制浏览器下载
核心是绕过任何字符串编码转换，原样输出二进制，并设置正确的响应头。PDO 默认可能把 BLOB 当字符串处理，导致截断或乱码。
- 用
PDO::ATTR_EMULATE_PREPARES => false关闭模拟预处理，避免 BLOB 被转成 UTF-8 字符串 - 查询后立即用
stream_get_contents()或直接$stmt->fetchColumn()拿原始字节，别用htmlspecialchars()或json_encode()处理 - 必须设置三组响应头：
Content-Type（如application/pdf）、Content-Length（用strlen($blob)）、Content-Disposition: attachment; filename="xxx.pdf" - 输出前调用
ob_end_clean()清空输出缓冲区，否则 HTML 模板残留内容会污染二进制流
header('Content-Type: application/octet-stream');
header('Content-Length: ' . strlen($blob));
header('Content-Disposition: attachment; filename="report.pdf"');
echo $blob;
前端点击下载时后端接口该怎么设计
不要让前端发个 GET 请求直接拿 BLOB 字段值（比如返回 base64 字符串再 atob()），大文件会爆内存、慢且不可暂停。最稳的方式是后端生成一个带签名的临时下载 URL，或者直接流式响应。
- 接口路径建议用
/api/download?id=123这类语义化路由，而不是暴露字段名或表名 - 务必校验权限：查
id对应记录是否存在、当前用户是否有权下载该文件（比如检查user_id或角色） - 如果文件较大（>10MB），考虑加
Content-Transfer-Encoding: binary和禁用 gzip（header('X-Content-Encoding: none')），避免 Nginx/Apache 自动压缩破坏二进制 - 别用
fetch().then(res => res.blob())再创建 URL 下载——对大文件依然吃内存；优先用<a href="/api/download?id=123" download>原生链接
PostgreSQL / SQLite 的 BLOB 导出有啥不同
逻辑一致，但驱动行为和字段类型名有差异。PostgreSQL 的 bytea 默认以转义字符串形式返回（如 \x47494638...），SQLite 的 BLOB 类型在大多数驱动里已原生支持二进制返回。
- PostgreSQL 必须在查询前执行
SET bytea_output = 'escape'或更好是'hex'，然后用pg_unescape_bytea()（PHP）或bytes.fromhex()（Python）还原 - SQLite 用
sqlite3.Binary()插入时，查询时一般可直接拿到bytes对象，但某些旧版本驱动仍需手动设置text_factory = bytes - 所有数据库都建议在建表时明确指定字段类型为
BLOB（SQLite）、BYTEA（PG）、LONGBLOB（MySQL），别用TEXT存二进制，容易因字符集损坏数据
PDO::ATTR_EMULATE_PREPARES 或忘了 ob_end_clean()。 
