【TiDB 使用环境】生产环境
【TiDB 版本】v6.5.9
【操作系统】
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】
【问题复现路径】业务上有一张表，主要存储大文本字段（一条数据最大20多MB），目前表结构定义为BLOB类型，在数据查询时涉及到这张表需要的内存就要很多，我想了解一下如果我将字段类型调整为LONGTEXT是否会对查询有优化一下
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
我们都是用longtext来存储的。查询的时候是按其他字段作为条件查询的，不会将longtext字段作为条件查询。
BLOB 大多用来存储图片，但是存储大字段会影响性能；
如果是图片的话，可以存在文件系统上，只在TIDB里面存储图片的路径；
blob 会好一些
都不要使用。。blob存储图片，文件，视频等等。大小很难评估。。longtext会导致表膨胀。。
项目上Blob一般是用来存图片的 ，如果是日志、json、xml建议 longtext
blob 迁移的时候不友好，有些库不支持
我们也是用于存储大文本内容的，都是字符串，只是有些内容会有几十兆，不会直接查询这个字段都是通过其他条件检索出来
blob大多数是为了存图片，longtext 我这边AI返回结果本来用varchar(6000)结果不够。就用longtext了。但是我给开发说这一列禁止创建索引，禁止用这个字段来做条件查询。用其他字段来筛选查询。
超大数据量的数据最好不存数据库
我得理解是blob对数据库更友好
主要还是得看存储内容吧。不同的内容选择不同的字段。
- 如果存储纯文本内容（如 JSON、HTML、富文本）：优先选择
LONGTEXT，压缩和查询效率更优。 - 如果存储二进制内容（如图片、音频、视频）：
BLOB是必需的，但建议将这类大文件存储到对象存储（如 S3、OSS），仅在 TiDB 中保存文件路径，避免直接存储大二进制数据。
| 操作场景 | LONGTEXT 支持情况 | BLOB 支持情况 | 对 TiDB 友好性 |
|---|---|---|---|
| 字符集 / 排序 | 支持 utf8mb4 等字符集，可按规则排序、比较 | 无字符集，仅按字节比较，无法文本排序 | LONGTEXT 更优 |
| 文本函数 | 支持 SUBSTRING/LENGTH/UPPER 等文本函数 | 仅支持字节级函数（如 LENGTH 算字节数），无文本函数 | LONGTEXT 更优 |
| 索引支持 | 可创建前缀索引（如前 300 字符），加速查询 | 仅能创建字节前缀索引，无实际文本检索意义 | LONGTEXT 更优 |
| 模糊查询 | 支持 LIKE 文本模糊匹配（利用前缀索引） | 仅支持字节级 LIKE，无法高效匹配文本 | LONGTEXT 更优 |
| JSON 处理 | 可存储 JSON 字符串，配合 JSON 函数解析 | 可存 JSON 字节流，但无法直接用 JSON 函数解析 | LONGTEXT 更优 |
我们生产实践上使用longtxt，二进制数据也是序列化之后再保存text。
text的性能能比得上blob吗,我感觉处理起来还是二进制快啊