大字段拆分是高并发/大数据量下的必要设计，非高频查询字段（如富文本、BLOB、JSON扩展数据、日志类文本）应移至扩展表；推荐一对一扩展表或独立宽表+延迟关联，并同步删除原字段、加外键索引、调整查询逻辑。
大字段（如 TEXT、BLOB、JSON、长 VARCHAR）直接放在主表中，会显著增加单行数据大小，拖慢查询、索引扫描、排序和内存使用。拆分它们不是“可选优化”，而是高并发或大数据量场景下的必要设计手段。
哪些字段适合拆到扩展表？
判断核心标准：是否高频参与 WHERE/JOIN/ORDER BY 或必须与主业务字段一起查？如果不是，就该考虑拆出。
- 富文本内容（文章正文、商品详情描述）——极少用于条件过滤，但体积常达几KB~MB
- 用户头像/附件路径或二进制数据（BLOB）——读取频次远低于用户基本信息
- 结构化扩展数据（JSON 字段存动态属性）——多数场景只在详情页按需加载
- 日志类、审计类长文本（操作记录、错误堆栈）——基本不参与业务查询逻辑
两种主流拆分方式及适用场景
不是所有拆分都叫“垂直分表”，要根据访问模式选对模型。
-
一对一扩展表（推荐）：新建表，用主表主键作外键（如
user_profiles(user_id PK, bio TEXT, avatar_url VARCHAR)）。适合字段与主记录强绑定、生命周期一致、查询有明确“主+扩”组合需求（如用户中心页） -
独立宽表+延迟关联：把大字段单独建表，但用业务唯一键（非主键）关联，例如
article_contents(article_slug, content TEXT)。适合 SEO 友好 URL 场景，避免主键暴露或需多版本内容管理
拆分后必须同步做的三件事
只拆不分，反而引入新问题。以下动作缺一不可：
- 删除原表中的大字段，并确认应用层已切换读写路径（别留“双写过渡期”陷阱）
-
为扩展表外键字段加索引（如
user_id），否则 JOIN 变全表扫描 - 调整应用查询逻辑：主表查询默认不 JOIN 扩展表；详情接口显式 LEFT JOIN 或分两步查（先主后扩），避免 N+1 或无谓加载
警惕“伪拆分”和隐形成本
有些做法看似拆了，实际没解决问题：
- 把大字段挪到另一张“宽表”，但每次查主表都强制 JOIN —— 表宽没降，IO 反而翻倍
- 用 JSON 字段替代多个列，却仍在 WHERE 中用
JSON_CONTAINS全表解析 —— 失去索引能力，CPU 更吃紧 - 未评估扩展表的写放大：高频更新大字段时，若扩展表无合理分区或归档策略，会导致 WAL 增长、备份变慢
基本上就这些。本质不是“把东西放哪儿”，而是“什么时候、以什么代价加载它”。拆分是手段，按需加载才是目标。
