TEXT/BLOB字段导致查询变慢的典型表现是加WHERE仍全表扫描、SELECT*卡顿、主从延迟飙升；应垂直拆分至独立表或改用对象存储，并同步更新ORM、备份及全文索引方案。
TEXT/BLOB 字段导致查询变慢的典型表现
加了 WHERE 条件却要全表扫描、SELECT * 响应明显卡顿、主从同步延迟飙升——这些八成不是索引没建好，而是 TEXT 或 BLOB 字段在拖后腿。MySQL 默认把这类大字段和行数据一起存，哪怕你只查 3 个字段，只要表里有 content（TEXT 类型），就得把整个大字段读进内存再丢弃。
垂直拆分：把大字段单独拎到另一张表
核心动作就一条：把原表里的 TEXT/BLOB 字段（比如 article_content）移到新表，用主键关联。不改业务逻辑，只改表结构和 SQL 写法。
实操建议：
- 新表命名直接体现用途，比如
article_content，主键与原表一致（id），外键可选但不强制 - 原表删掉
article_content字段，保留id和其他高频访问字段（title、status等） - 读取时按需
JOIN：列表页只查原表；详情页才LEFT JOIN article_content - 写入时用事务包住两表操作，避免出现“有头无身”（主表有记录，内容表没写入）
独立存储：用对象存储替代数据库存大文本
当内容体积持续超 1MB、或需要 CDN 加速、版本管理、权限隔离时，数据库已不是最优载体。这时把 TEXT 内容转成文件，存到 MinIO、S3 或本地 /data/uploads/，数据库只留一个 content_url 字段。
关键细节：
-
content_url必须是完整可访问路径（如https://cdn.example.com/articles/12345.txt），别存相对路径或 ID - 上传失败必须回滚主表插入，否则页面加载时会 404
- 如果旧数据要迁移，别用
SELECT ... INTO OUTFILE直接导出——它不处理换行/引号，容易损坏内容；改用应用层逐条读取 + 写文件 - 注意对象存储的鉴权粒度：公开读？临时签名？别让
content_url暴露内部路径或密钥
拆分后容易被忽略的三个点
垂直拆分不是一拆就灵，有些坑藏在细节里：
- ORM 框架默认 eager load 可能自动
JOIN内容表，查列表页也拉大字段——得显式关掉，或改用 lazy load - 备份脚本若仍按旧表结构 dump，会漏掉新表，恢复后数据不一致；所有自动化流程（备份、审计、ETL）都得同步更新
- 如果原表有全文索引在
content字段上，拆出去后MATCH ... AGAINST就失效了，得用Elasticsearch或MyISAM单独建索引表
真正麻烦的从来不是拆，而是拆完之后所有依赖它的环节是否都被重新捋过一遍。
