Navicat 15 默认不截断BLOB长度，仅在结果网格显示前若干字节并标注“[BLOB]”；真正影响性能的是全量加载二进制内容，而非显示策略。
navicat 15 默认不会对 blob 字段内容做长度截断，但会在结果网格中只显示前若干字节（通常几十到几百字节），并附带“[blob]”提示——这看起来像限制了长度，其实只是显示策略，真正影响查询性能和内存占用的是返回完整 blob 数据本身。想在 sql 编辑器中安全执行含 blob 字段的查询，关键不是“限制字段长度”，而是避免 select 全量加载二进制内容。
为什么不能靠 SELECT ... LIMIT 控制 BLOB 字段长度
SELECT 语句里的 LIMIT 只控制行数，不控制单个字段的字节数。即使你写 SELECT id, SUBSTRING(blob_col, 1, 100) FROM t，只要表里某行 blob_col 实际是 50MB，MySQL 仍需把整块数据从磁盘读入内存、再截取，Navicat 也会尝试接收并缓存它——这极易触发“内存不足”或卡死。
- Navicat 的“记录”设置（工具 → 选项 → 记录 → 限制记录数）只限制返回行数，对
BLOB字段的单行体积毫无约束 - “BLOB 长度限制”（工具 → 选项 → 数据）仅影响网格视图里显示的预览字节数，不影响实际传输和内存分配
- 真正起作用的是 MySQL 的
max_allowed_packet和 Navicat 自身的缓存策略，而非 SQL 语法层面的“长度限制”
安全查 BLOB 字段的三种实操方式
目标是：看到关键信息（比如是否为空、大小、类型），但不加载全部二进制内容。
- 用
LENGTH()替代直接 SELECT：SELECT id, LENGTH(blob_col), mime_type FROM files WHERE id = 123;—— 返回的是整数，毫秒级响应 - 用
HEX()截取头部特征：SELECT id, HEX(LEFT(blob_col, 8)) AS hex_head FROM files LIMIT 10;—— 看前 8 字节十六进制，判断是否为 PNG/JPEG 等 - 加条件过滤空值或小文件：
SELECT id FROM files WHERE blob_col IS NOT NULL AND LENGTH(blob_col) —— 把大对象排除在结果集外
编辑器里执行前必须检查的两个 Navicat 设置
这两个设置不改，再小心写 SQL 也可能被后台自动加载拖垮：
- 工具 → 选项 → 数据 → “BLOB 长度限制”：建议设为
1024（1KB），避免网格试图渲染超长预览 - 工具 → 选项 → 记录 → “限制记录数”：含
BLOB的表，别设成10000；建议100起步，确认逻辑无误后再逐步放开 - 额外提醒：关闭“自动保存查询结果到内存”（工具 → 选项 → 其他 → 查询结果 → 取消勾选“将结果保存在内存中”），改用临时文件缓存
当真要查某一行完整 BLOB 时，必须做的三件事
比如调试某张图片损坏问题，需要看原始字节——这时必须主动降级风险：
- 先用
SELECT LENGTH(blob_col) FROM t WHERE id = ?确认大小，若超过 5MB，放弃直接 SELECT，改用导出功能 - 在 SQL 编辑器中手动添加
LIMIT 1，且确保 WHERE 条件能命中唯一主键，防止意外扫全表 - 执行前点击 Navicat 工具栏的
取消按钮（红色方块），随时中断；一旦光标变圈、状态栏显示“正在获取数据”，立即按 Esc 或点取消——BLOB 查询没有“进度条”，卡住就是内存已爆
最常被忽略的一点：Navicat 的“结果网格”右键菜单里有“导出所选行”，但它默认仍会把整行（含完整 BLOB）加载进内存才导出。真要导出大 BLOB，请绕过编辑器，直接用右键表 → 导出向导 → 选 XML 格式——那是唯一经过二进制安全编码、支持分片和压缩的路径。
