TEXT/BLOB字段拖慢查询因其存储分离导致额外IO，易引发全表扫描、内存OOM及索引失效；应避免无条件SELECT、合理设前缀索引、用虚拟列或外部存储替代。
TEXT/BLOB 字段为什么拖慢查询
因为它们通常不存于主数据页，而是单独分配存储页，InnoDB 中还会触发额外的二级索引回表或外部溢出页读取。一旦 SELECT * 或未加 WHERE 条件的查询涉及这些字段，就会强制加载大量非必要二进制内容，IO 和网络开销陡增。
常见错误现象包括：EXPLAIN 显示 type=ALL 且 rows 极大、慢查询日志里频繁出现含 TEXT 字段的语句、应用层内存 OOM（尤其 ORM 自动映射全字段时）。
- 避免在
WHERE、ORDER BY、GROUP BY中直接使用TEXT/BLOB字段——MySQL 不支持对它们建完整索引（仅前缀索引可用） - 不在
SELECT列表中无条件包含TEXT/BLOB，改用显式字段名，或拆分查询（先查 ID + 元数据，再按需SELECT content） - InnoDB 表中，若单行超过 8KB，
TEXT会自动转为外部存储，加剧随机 IO；可考虑压缩后存入MEDIUMTEXT（上限 16MB），而非盲目用LONGTEXT
如何给 TEXT 字段加有效索引
MySQL 对 TEXT 类型只允许前缀索引，但前缀长度选错就等于没索引。比如对 JSON 内容做模糊匹配，INDEX(content(255)) 可能刚够覆盖 {"status":"active","user_id":123} 这类短结构，但对长日志文本完全无效。
实操建议：
- 先用
SELECT MAX(CHAR_LENGTH(content)) FROM tbl WHERE ...估算典型值分布，再取 P95 长度 × 0.7 作为前缀长度参考 - 对确定以固定前缀开头的内容（如 Markdown 文档以
#开头、日志以[INFO]打头），可用INDEX(content(10))加速WHERE content LIKE '[INFO]%' - 不要对
BLOB建前缀索引——二进制内容无字符语义，LIKE失效，SUBSTRING()计算开销大；应提取特征后存入独立VARCHAR字段并索引
查询时绕过 TEXT/BLOB 的三种写法
核心思路是让优化器跳过溢出页读取。以下写法在 MySQL 5.7+ 和 8.0 中均有效，且不依赖应用层改造。
- 用
SELECT id, title, created_at FROM article替代SELECT *，确保执行计划中Extra不出现Using where; Using filesort后还带大字段加载 - 对需要条件过滤但又不想查内容的场景，改用虚拟列：
ALTER TABLE article ADD COLUMN content_hash CHAR(32) AS (MD5(content)) STORED;
然后CREATE INDEX idx_content_hash ON article(content_hash)，用哈希值代替原文匹配 - 用
SELECT ... INTO DUMPFILE或应用层流式读取处理超大BLOB，避免一次性载入内存；配合SET SESSION max_allowed_packet = 268435456（256MB）防截断
替代方案：什么时候该放弃 TEXT/BLOB
不是所有“大内容”都适合塞进数据库。当单表 TEXT 字段平均长度 > 1MB、或 QPS > 100 的查询中 30% 涉及该字段时，存储成本和锁竞争已远超收益。
更合理的做法：
- 把原始文件存对象存储（如 S3 / MinIO），数据库只留
file_url和file_size等元数据，用 CDN 加速访问 - 对富文本内容，抽离结构化字段：如
summary（VARCHAR(500)）、tags（JSON）、word_count（INT），再配全文索引或 Elasticsearch - 若必须本地存，优先用
MEDIUMTEXT而非LONGTEXT，并开启innodb_file_per_table=ON+innodb_large_prefix=ON，避免系统表空间膨胀
真正难处理的从来不是字段类型本身，而是业务逻辑里那些“可能要查全文”的模糊需求——它会让所有优化提前失效。
