垂直分库、垂直分表、水平分库、水平分表有什么区别？
简化版
垂直拆分按业务或字段拆，解决耦合和单行过宽问题；水平拆分按数据行拆，解决单表数据量和单库吞吐问题。分库强调资源隔离和吞吐扩展，分表强调降低单表规模和索引压力。
详细版
四种概念可以这样区分：
| 方式 | 拆分维度 | 例子 | 主要目标 |
|---|---|---|---|
| 垂直分库 | 按业务模块拆库 | 用户库、订单库、支付库 | 业务隔离、资源隔离 |
| 垂直分表 | 按字段冷热/宽窄拆表 | 用户基础表、用户扩展表 | 减少行宽、提升缓存命中 |
| 水平分库 | 同一张逻辑表按行拆到多个库 | order 库 0 到 3 | 分摊数据库实例压力 |
| 水平分表 | 同一张逻辑表按行拆成多张表 | order_00 到 order_63 | 降低单表数据量和索引规模 |
实际落地常常组合：订单业务先从大库中垂直分出订单库，再把订单表按 user_id 水平分到多个库表。选型时要看瓶颈在哪里：如果是业务耦合和资源抢占，优先垂直拆；如果是单表数据量和单实例吞吐，考虑水平拆。
完整版教学
一、垂直拆分关注“业务边界”和“字段结构”
垂直分库是把不同业务模块拆到不同数据库。比如一个早期系统只有一个 app 库，里面有 user、order、payment、inventory。随着业务增长，订单写入非常高，支付对一致性要求高，用户数据又涉及隐私权限。如果继续放在一个库，任何一个模块的压力或变更都会影响其他模块。垂直分库后，订单库可以独立扩容，支付库可以更严格地控制权限和审计，用户库可以单独做脱敏和备份策略。
垂直分表则是表内部字段层面的拆分。典型例子是用户表：id、name、phone、status 属于高频访问字段，而 avatar、profile、settings、bio 等大字段或低频字段会拉宽整行。InnoDB 读取数据页时是按页加载，行越宽，一个页能容纳的记录越少，热点查询的缓存效率就越低。把低频大字段拆到扩展表，可以让主表更轻。
二、水平拆分关注“数据量”和“实例压力”
水平分表是把一张逻辑表的不同记录拆到多张物理表。比如 order 表按 user_id % 64 拆成 order_00 到 order_63。每张表数据少了，索引体积变小，单表维护成本下降。
水平分库进一步把这些分表放到不同数据库实例上。只分表但还在同一个库里，能降低单表大小，却不能突破单实例 CPU、IO、连接数、日志写入能力的瓶颈。分库后，请求可以落到不同实例，吞吐上限才真正扩展。
可以这样理解：分表主要减轻“表”的压力，分库主要减轻“实例”的压力。线上很多系统会采用“分库 + 分表”：比如 4 个库，每个库 16 张表，总共 64 个物理表。
三、四种方式带来的问题不同
垂直分库后，最大的问题是跨业务一致性和跨库查询。原来下单时可以在一个本地事务里写订单、扣库存、写支付流水，拆库后就变成分布式事务或最终一致性问题。原来一个 Join 能查出用户和订单，拆库后通常要改成服务调用或数据冗余。
垂直分表的问题是查询路径变多。主表和扩展表之间通常是一对一关系，如果页面需要完整资料，仍然要回表或二次查询。设计时要把高频字段留在主表，低频大字段拆出去，否则会适得其反。
水平分库分表的问题更多：分片键、路由、全局 ID、跨分片排序分页、扩容迁移、热点分片、唯一约束都要重新设计。如果查询都能带上分片键，水平拆分收益很明显；如果大量查询没有分片键，就会频繁广播，成本很高。
四、怎么判断该用哪一种拆法
可以从瓶颈反推方案：
| 当前瓶颈 | 更匹配的拆法 | 判断依据 |
|---|---|---|
| 不同业务互相影响 | 垂直分库 | 订单高峰拖慢用户、支付等模块 |
| 表字段太多、行太宽 | 垂直分表 | 高频查询只需要少数字段 |
| 单表行数过大 | 水平分表 | 索引膨胀、DDL/归档困难 |
| 单实例写入或 IO 到顶 | 水平分库 | CPU、IO、连接数、redo/binlog 压力高 |
一个常见误区是只看“表有多少行”。比如一张日志表有 2 亿行，但只追加写、按时间归档、查询走冷热分离，它未必急着分库分表。反过来，一张订单表只有几千万行，但写入高峰强、索引多、查询复杂、DDL 窗口不可控，就可能需要拆。
五、面试回答可以按“定义—场景—代价”组织
面试官问区别时，不要只背四个定义。更好的回答是先给定义，再说明解决什么问题，最后说代价。例如：
垂直拆分解决业务耦合和表结构臃肿，水平拆分解决同类数据的容量与吞吐；分库解决实例资源瓶颈，分表解决单表规模问题。拆完以后，跨库事务、跨分片查询、全局唯一和扩容迁移都要额外设计。这个结构说明你不是只知道名词，而是知道它们在真实系统里的取舍。
六、四种拆分方式在工程中的组合顺序
真实项目很少只使用某一种拆法。常见演进路线是先垂直拆，再水平拆。早期系统所有表在一个库里，先按业务边界拆成用户库、订单库、支付库、库存库，这一步解决的是组织边界和资源隔离问题。订单库增长到一定规模后，再对订单表做水平分库分表，这一步解决的是同类数据容量和吞吐问题。
垂直分表通常发生在单表字段过宽或冷热字段明显分离时。比如用户主表只保留登录、状态、手机号等高频字段，把头像、简介、偏好设置等低频大字段拆到扩展表。它不一定提升写入吞吐，但能提升缓存命中率，让高频查询读取更少的数据页。
水平分库和水平分表经常一起设计。如果只水平分表但仍在同一个数据库实例上，单表索引变小了，但实例 CPU、IO、连接数、redo/binlog 压力并没有被拆开。如果瓶颈已经在实例层面，就需要分库。反过来，如果只是单表太大、实例资源还有余量，先分表也可能足够。高分答案要能把“表级问题”和“实例级问题”分开说。
七、容易混淆的边界和反例
垂直分库不是微服务的同义词。微服务强调业务能力和部署边界，垂直分库强调数据资源和数据所有权。两者常常一起出现，但不是必须绑定。一个单体应用也可以把数据库垂直拆成多个库，一个微服务也可能多个服务短期共用一个库，只是后者会带来耦合风险。
水平分表也不是分区表的完全替代。数据库原生分区表对应用更透明，适合一定规模下的范围管理和归档；分库分表更强调突破单实例容量或吞吐上限，但应用和中间件复杂度更高。面试时如果能补充“优先考虑原生分区、归档、索引和读写分离，再决定是否分库分表”，答案会更稳。
还有一个反例：按订单状态做水平分表，看起来查询状态很方便，但状态基数低、分布极不均，而且订单状态会变化，数据需要跨表移动，通常不是好分片键。通过反例说明你知道拆分不是按字段随便切，而是要服务稳定、高频、均匀的访问路径。
八、常见误区与追问
这道题要紧扣「垂直拆分与水平拆分」本身回答，不能把它混成泛泛的分库分表套话。面试官通常不是只听定义，而是看你能不能把适用场景、关键流程、失败边界和工程取舍串起来，尤其要说明拆分边界、路由规则、扩容迁移、跨库查询和一致性兜底。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 垂直拆分按业务或字段拆，解决耦合和宽表；水平拆分按数据行拆，解决单表数据量和吞吐瓶颈 | 不要停在名词解释 |
| 流程机制 | 判断瓶颈类型 -> 先按业务垂直拆边界 -> 再对大表水平拆行 -> 设计路由和事务 -> 改造查询聚合 -> 监控容量增长 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 用户表 2 亿行适合水平分表，用户资料和登录凭证职责不同则适合垂直拆分 | 分库分表能扩展容量和吞吐，但会带来路由、事务、Join、唯一约束、扩容和运维复杂度 |
垂直拆分与水平拆分 面试拆解：
1. 判断瓶颈类型
2. 先按业务垂直拆边界
3. 再对大表水平拆行
4. 设计路由和事务
5. 改造查询聚合
6. 监控容量增长记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「垂直拆分与水平拆分」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：垂直拆分和水平拆分只是名字不同。 一个按业务边界拆，一个按行数据规模拆，解决的问题不同。
- 误区：一上来就水平分库。 如果问题是业务耦合或宽表，先垂直拆分更自然。
- 误区：拆完性能一定变好。 跨库事务、Join 和运维复杂度会增加。
- 追问：什么时候水平拆？ 单表数据量、写入吞吐、索引维护或存储容量接近瓶颈时。
- 追问：什么时候垂直拆？ 业务边界清晰、字段冷热不同、团队职责不同或库压力耦合时。
- 追问：两者能一起用吗？ 常见做法是先垂直拆业务库，再对核心大表水平分片。
九、加强记忆
把“垂直”和“水平”想成两个方向：垂直是按列、按业务边界把东西拆开；水平是按行、按分片规则把同类数据摊开。再记住“库是资源单位，表是数据组织单位”，就不容易把垂直分库、垂直分表、水平分库、水平分表混在一起。