垂直拆分是解决宽表查询慢的根本方案，需依据字段访问频次与共查模式拆分：主表存高频小字段，大字段或低频字段分至扩展表，并迁移至独立存储以提升缓存效率。
宽表查询慢，不是加索引就能解决的——字段太多、单行太宽，IO和缓存效率天然受限。垂直拆分是更底层、更有效的解法。
什么时候该考虑垂直拆分？
别等 EXPLAIN 显示“Using temporary”或“Using filesort”才行动。以下信号出现时，就该动手了：
-
SELECT *扫描一行要读几百字节，但业务实际只用其中 3–5 个字段（比如查用户列表只要id、name、status） - 表里有
TEXT、BLOB或大 JSON 字段（如settings_json、profile_data），且它们极少被查询或更新 - 字段数超过 40，且明显分属不同访问频次：高频字段（登录态、状态、时间戳） vs 低频字段（头像URL、个人简介、历史操作日志）
-
innodb_buffer_pool_read_requests高但innodb_buffer_pool_reads也高，说明缓存命中率差，本质是单行太大挤占缓存空间
怎么拆？按访问模式而不是“看起来像一类”
拆错比不拆更麻烦。关键不是“语义归类”，而是“谁和谁总是一起查”。常见错误是把所有“用户资料”塞进 user_profile，结果登录接口还得 JOIN 两次。
- 主表只放高频、必查、小体积字段：
id、username、email、status、created_at、updated_at - 认证相关字段（
password_hash、salt、last_login_at）单独建user_auth表，登录/改密才 JOIN - 大字段或低频字段（
avatar_url、bio、settings_json）放进user_meta，除非编辑个人资料，否则不查 - 避免“一拆到底”：不要为每个字段建一张表；JOIN 超过 2 张表会显著拖慢简单查询
拆完必须同步改代码和索引
只改表结构不改应用，等于白干。尤其注意外键和事务边界：
- 主表
id必须是PRIMARY KEY，扩展表的user_id要建UNIQUE约束（不是外键，避免级联锁表） - 原来
UPDATE users SET avatar_url=?, bio=? WHERE id=?要拆成两条语句，用同一事务包裹 - 原来
SELECT * FROM users WHERE status='active'变成SELECT id, username, email, status FROM users WHERE status='active'—— 别再SELECT * - 如果扩展表字段也要查，加
LEFT JOIN，但确保ON user.id = user_meta.user_id的列上有索引
容易踩的坑：冷热分离没做，反而更慢
垂直拆分后，如果所有表都放在同一个库、同一个磁盘上，IO 瓶颈只是从“一行读太多”变成“多表并发读”，性能可能不升反降。
- 把
user_meta这类低频大字段表，迁到独立的 SSD 实例或更低配存储上（只要能接受稍高延迟） - 确认
innodb_buffer_pool_size没被新表撑爆：主表数据热，缓存应优先保障；扩展表数据冷，缓存命中率低，别让它吃掉主表的内存 - 监控
Handler_read_rnd_next：如果这个值飙升，说明 JOIN 后排序/临时表变多，得回头检查是否拆得太碎或缺少覆盖索引
真正难的不是“怎么拆”，而是判断哪些字段算“低频”、哪些组合算“高频共查”。这没法靠规则，得看真实慢查询日志里 WHERE 和 SELECT 的实际字段组合，而不是开发脑补。
