“转储SQL文件”不适用于含大量BLOB的表，因其将BLOB转为十六进制导致文件膨胀、超max_allowed_packet报错、导入数据损坏；应改用“导出向导→XML格式”，并调高max_allowed_packet至256M、取消勾选“将BLOB字段转换为十六进制”，再通过Base64解码比对长度验证完整性。
不能用“转储SQL文件”导出含大量BLOB的表——它会报错、膨胀、卡死，且无法还原原始二进制内容。
为什么“转储SQL文件”对BLOB完全不适用
Navicat 的「转储SQL文件」功能会把 BLOB 字段值转成十六进制字符串（如 0x89504E47...）写入 SQL 文件。这带来三个硬伤：
- 文件体积翻倍甚至更多：一张 5MB 的 PNG 导出后 SQL 文件可能超 10MB，解析和导入时内存压力陡增
- MySQL 服务端拒绝执行：一旦单条
INSERT语句含多个大 BLOB，总长度超过max_allowed_packet（默认常为 4MB/16MB），直接报错Got a packet bigger than 'max_allowed_packet' bytes - 导入后数据损坏风险高：部分版本 Navicat 在 SQL 导入阶段对长十六进制串解析不稳定，容易截断或乱码
必须用“导出向导 → XML 格式”并调高 max_allowed_packet
XML 是 Navicat 中唯一能原样保留 BLOB 二进制流的导出格式（不编码、不转义），但前提是 MySQL 服务端允许接收足够大的数据包。
炫酷的jQuery二进制数字时钟
下载
炫酷的jQuery二进制数字时钟，它的时分秒都是用二进制来表示，绿色表示该位值是1，灰色则表示0，原理是将时钟的时分秒分别实时转换成二进制，然后随着本地时间的更新而实时刷新
- 先在 MySQL 配置文件（
my.ini或my.cnf）的[mysqld]段添加：max_allowed_packet = 256M - 重启 MySQL 服务（不重启配置不生效）
- 在 Navicat 中右键目标表 → 「导出向导」→ 格式选
XML→ 勾选「导出数据」 - 关键设置：在「导出选项」页，取消勾选「将 BLOB 字段转换为十六进制」（这个选项默认关闭，但务必确认）
- 导出生成的 .xml 文件可直接用于后续「从 XML 导入」，BLOB 内容零损失
导出后如何验证 BLOB 完整性
导出完成不代表万事大吉，尤其当表里有上百个 mediumblob 字段时，得快速确认是否真没丢字节：
- 用 Navicat 打开导出的 XML 文件（支持直接双击打开），展开任意一条记录，看
<field name="img_data"></field>标签下是否是 Base64 编码的原始字节（而非0x...十六进制） - 对比源表与 XML 中同一行的 BLOB 字段长度：执行
SELECT LENGTH(img_blob) FROM t WHERE id = 123，再在 XML 里找对应<field></field>标签，用 Base64 解码后取len()，二者应严格相等 - 避免用文本编辑器直接打开大 XML 文件——可能因加载失败而误判；优先用 Navicat 自带的 XML 查看器或命令行
base64 -d+wc -c校验
超大表（如含 82 个 mediumblob 字段）要分批导出
即使调高了 max_allowed_packet，单次导出整张表仍可能触发 Navicat 客户端内存溢出（尤其 Windows 上 32 位进程限制约 2GB）。这时必须切片：
- 不要依赖「导出向导」默认的“全部行”，改用「使用查询导出」：在导出步骤中选择「使用查询」，填入类似
SELECT * FROM t WHERE id BETWEEN 1 AND 5000 - 每批控制在 3000–5000 行以内，具体上限取决于单行平均 BLOB 大小；例如平均单行 20MB，则 500 行就已达 10GB 传输量，必须更细粒度
- 导出的多个 XML 文件命名建议带范围标识，如
t_img_0001-0500.xml，方便后续按序导入不漏不重
真正麻烦的不是操作步骤多，而是所有环节都依赖「服务端参数+客户端格式+校验动作」三者严丝合缝——漏调一个 max_allowed_packet，或误勾一个十六进制选项，导出来的 XML 看似正常，实际已不可逆损坏。
