为什么MySQL建议把大字段Blob或Text做垂直分表

垂直分表可显著提升性能，因TEXT/BLOB字段导致SELECT *时需多次随机IO读取溢出页、降低缓冲池命中率、强制加载无用数据；应按访问频率拆分，如商品主表留常用字段、详情字段移至独立表并确保JOIN索引。

因为大字段会拖慢高频查询、增加随机IO、浪费缓冲池空间，垂直分表能直接切掉这些负担。

为什么 SELECT * 会变慢

MySQL 的 InnoDB 数据页默认是 16KB。当表里有 TEXT 或 BLOB 字段时，哪怕只存前 768 字节在主数据页，其余内容仍需额外读取溢出页（off-page），每次 SELECT * 都可能触发多次随机磁盘 IO —— 尤其是 LIMIT 10 这种看似轻量的语句，实际要拉取 10 条记录的全部字段，包括每条记录背后隐藏的溢出页。

• 主表越宽，单页能存的行数越少，缓冲池命中率越低
• TEXT/BLOB 不参与索引，却强制随主键一起被加载，属于典型的“无用带宽”
• 即使应用层只用 title 和 cover_img，数据库仍得把 detail 全部捞出来

TEXT 和 BLOB 的特殊行为加剧问题

它们不只是“大”，还自带限制和隐性开销：

• Strict Mode 下不能设默认值：ERROR 1101 (42000): BLOB/TEXT column 'xxx' can't have a default value
• 排序只取前 max_sort_length 字节（默认 1024），ORDER BY detail 实际不按全文排
• 无法建前缀以外的索引，WHERE detail LIKE '%xxx%' 几乎只能全表扫描
• 复制和备份时体积膨胀，主从延迟风险升高

垂直分表不是“拆着玩”，而是按访问模式切

关键不在字段大小，而在使用频率和组合关系。比如商品表中：

• product 表保留 id、title、price、left_num —— 所有列表页、搜索页、购物车都查它
• product_detail 放 learn_base、detail、summary —— 只在详情页按需 JOIN
• 两个表共用 id 作为逻辑主键，但 product_detail.product_id 必须加索引，否则 JOIN 成性能黑洞

这种切法让 95% 的请求避开大字段，同时避免了水平分表带来的分布式事务、跨库 JOIN 等复杂度。

容易忽略的细节：外键、事务与同步成本

MySQL 原生不支持跨表外键（尤其分表后），所以 INSERT 必须由应用层保证原子性：

• 不能依赖单条 SQL 完成两表写入，得用事务包裹两个 INSERT
• 如果用触发器自动同步，小数据量尚可；一旦日增百万级，触发器本身就成了瓶颈
• 字段注释、字符集、时间字段（create_time）必须手动对齐，否则后续 JOIN 可能因隐式转换失效索引

真正难的从来不是怎么拆，而是拆完之后——谁来保证 product 和 product_detail 的生命周期始终一致。