深度解析MySQL为何建议将Blob/Text大字段垂直分表

在MySQL表结构设计中，垂直分表是一个被反复提及却又很容易被轻视的话题。很多人知道大字段会拖慢性能，但具体慢在哪里、怎么拆才合理，往往讲不清楚。今天就把这件事彻底理一遍——从为什么SELECT *会被大字段拖垮，到按什么逻辑切表，再到拆完之后那些容易踩的坑。

先说说最直接的性能杀手：当表里躺着TEXT或BLOB字段，每一次SELECT *都相当于在走钢丝。MySQL的InnoDB数据页默认是16KB，大字段哪怕只存前768字节在主数据页，剩下的内容仍然需要额外读取溢出页。这意味着，哪怕只是LIMIT 10这样看起来人畜无害的查询，背后可能藏着十多次随机磁盘IO——每条记录都有一个“尾巴”要拉，跑不掉的。

更隐蔽的是，大字段的存在会让主表变“胖”。主表越宽，单页能容纳的行数就越少，缓冲池命中率自然跟着下降。而那些TEXT或BLOB本身并不参与索引判断，却强制随着主键一起被加载进来——典型的“无用带宽”，却要你为它买单。就算应用层只用到title和cover_img，数据库也得把整个detail字段完整捞出来，毫无商量余地。

到这里其实已经很清楚：垂直分表的初衷，就是把高频查询从大字段的负担中解放出来。

为什么 SELECT * 会变慢

关键就在于InnoDB的存储机制。当表里含有TEXT或BLOB字段时，即使它只占几百字节，大部分内容仍然存放在溢出页中。主数据页只保留一个引用指针，每次查询都要根据这个指针再去读额外的页。如果这些溢出页在磁盘上的位置不连续，那就是妥妥的随机IO——性能直接被拉低一个量级。

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

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

这两个类型不只是“大”，它们还自带一系列限制和隐性开销：

• Strict Mode下不能设置默认值，否则会报ERROR 1101 (42000): BLOB/TEXT column 'xxx' can't ha ve 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原生不支持跨表外键（尤其分表之后），所以写入时必须由应用层保证原子性：

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

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