垂直拆分需先确认必要性：单行超8KB拖慢查询，但若多数查询仍需全字段，则拆表反增JOIN开销；应按访问频率与数据类型热冷分离，如TEXT/BLOB移出，VARCHAR(255)级字段不建议拆。
垂直拆分字段前先确认是否真有必要
单行记录过大（比如超 8KB）会显著拖慢查询速度，尤其在 SELECT * 或全表扫描时触发大量磁盘 IO。但不是所有“字段多”都该拆——如果多数查询仍需同时读取所有字段，拆表反而增加 JOIN 开销和事务复杂度。优先检查：SHOW TABLE STATUS LIKE 'your_table' 中的 Avg_row_length 和 Data_length；用 SELECT LENGTH(column_name) FROM your_table ORDER BY LENGTH(column_name) DESC LIMIT 5 找出真正占空间的大字段（如 TEXT、BLOB、长 JSON）。
按访问频率和数据类型决定拆哪些字段
垂直拆分字段的核心逻辑是“热冷分离”：高频访问的小字段留在主表，低频/大体积字段移出。常见组合包括：
-
TEXT/MEDIUMTEXT字段（如商品描述、用户反馈内容）必须拆，它们不走内存缓存，IO 成本高 -
BLOB/LONGTEXT（如图片 base64、PDF 内容）应彻底移出数据库，改存对象存储 + URL 字段保留 - 历史字段（如
old_phone、last_login_ip_history）若仅审计用，单独建_archive表 - JSON 字段若只偶尔解析（如配置项），可拆；若高频
JSON_EXTRACT查询，反而不如保留并加虚拟列索引
不要拆 VARCHAR(255) 级别的常规字段（如地址、昵称），它们实际存储长度可控，拆表收益远低于维护成本。
拆表后必须处理好主键关联与一致性
垂直拆分字段本质是“一对一”表关系，主键必须严格对齐：
- 扩展表的主键应直接复用原表主键（如
user_id），不另设自增 ID —— 否则无法保证强一致，且INSERT需两阶段提交 - 务必给扩展表的外键字段加
UNIQUE约束（哪怕没显式定义外键），防止脏数据导致LEFT JOIN出现重复或丢失 - 写操作要原子化：应用层需用同一事务包裹主表和扩展表的
INSERT/UPDATE；若用 ORM，确认其支持跨表事务（如 Laravel 的DB::transaction()） - 避免在扩展表加业务索引（如按
description模糊搜索）—— 这类需求更适合同步到 Elasticsearch
示例语句：
CREATE TABLE user_extra ( user_id BIGINT PRIMARY KEY, bio TEXT, avatar_url VARCHAR(512), updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user_id (user_id) ) ENGINE=InnoDB;
JOIN 查询性能比你想象中更敏感
即使是一对一 JOIN，MySQL 优化器也可能放弃使用索引，尤其当扩展表数据量增长后：
- 主表
WHERE条件尽量不跨表（如避免WHERE u.status = 1 AND e.bio LIKE '%xxx%'），否则易触发全表 JOIN - 高频场景下，宁可用两次查询（先查主表 ID，再
IN查扩展表），也别依赖LEFT JOIN—— 尤其在分页LIMIT场景，JOIN会先膨胀再裁剪，代价翻倍 - 如果业务允许，把部分扩展字段冗余进主表（如
bio_preview前 100 字符），换取 90% 场景免 JOIN
真正容易被忽略的是：垂直拆分后，EXPLAIN 显示的 rows 可能骤增，但你只盯着主表的 key 是否命中，忘了扩展表的 type 是 ALL 还是 const。
