必须先悬停点击“显示二进制内容”进入十六进制视图，再选SQL格式并勾选Hexadecimal，否则BLOB导出必然不完整。
导出前没点Hex按钮，BLOB就不可能完整
phpmyadmin 默认用文本模式渲染 blob 字段，遇到非 utf-8 字节、控制字符或 null 字节时会直接截断、替换为 或显示为空。所谓“不完整”，90% 是因为压根没切换到十六进制视图——这不是导出设置问题，是浏览阶段就卡住了。
- 打开表 → 点击某行含 BLOB 的记录 → 将鼠标悬停在
[BLOB]上 → 出现「显示二进制内容」链接 → 必须点击它 - 点击后弹窗里看到的是
0x474946383961...这种格式，才代表已进入十六进制路径 - 该操作只对当前行生效；批量导出前，得逐行确认每条 BLOB 都已手动触发 Hex 视图
-
TEXT类型字段不会出现这个按钮，别混淆；TINYBLOB/MEDIUMBLOB/LONGBLOB行为一致
选错导出格式，Hex选项根本不起作用
Hexadecimal 复选框只在导出格式为 SQL 时生效，且仅影响 INSERT 语句中的 VALUES 部分。选 CSV、JSON 或 Excel 时，这个勾完全被忽略，导出结果仍是原始二进制流（被 Excel 或记事本当作损坏文件）。
- 必须选
SQL格式 + 勾选Hexadecimal+ 浏览时已切换为 Hex 视图，三者缺一不可 - 导出的 SQL 语句应形如：
INSERT INTO `table` VALUES (0x474946383961)，这才是标准十六进制标记 - 若选
JSON，即使字段已显示为 Hex，导出仍为 base64 字符串（如"R0lGODlh"），不是十六进制 -
CSV导出 BLOB 永远是空或乱码，别试
大 BLOB 导出失败，其实是内存和超时撑不住
十六进制字符串长度是原始数据的两倍，加上 SQL 包裹（INSERT INTO ... VALUES (0x...)），导出 1MB 的 BLOB 可能生成 3MB+ 的纯文本。phpMyAdmin 和底层 PHP 很容易在此过程中超限。
- PHP 层：需调高
upload_max_filesize、post_max_size、memory_limit、max_execution_time - phpMyAdmin 层：大 BLOB 建议改用命令行
mysqldump --hex-blob，绕过 Web 限制 - 导出页底部可手动指定「导出字符集」，避免因编码转换引发额外截断
- 如果只是想提取单个 BLOB，不如直接用
SELECT HEX(column) FROM table WHERE id = ?，结果复制粘贴更稳
导出后打开还是乱码，说明没走对路径
导出文件用文本编辑器打开看到一堆 0x 开头的字符串，但导入后 BLOB 内容异常，大概率是导出时漏了关键条件：浏览未切 Hex + 导出未选 SQL + Hexadecimal 未勾选。三者任一缺失，生成的 SQL 就不是标准十六进制字面量。
- 检查导出的 SQL 文件：确认有
0x前缀，且没有混入UNHEX('...')或 base64 形式 - 导入时若报错
Packet too large，需在 SQL 文件开头加：SET SESSION max_allowed_packet = 67108864; - 别依赖 phpMyAdmin 的“自定义导出”界面，它对长十六进制支持不稳定；真要批量处理，写个 Python 脚本读取 BLOB 并生成干净 INSERT 更可靠
