垂直分表可显著提升性能，因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 的生命周期始终一致。
