20250218 隨筆垂直分库分表（Vertical Sharding）和水平分库分表（Horizontal Sharding）

垂直分库分表（Vertical Sharding） 和 水平分库分表（Horizontal Sharding） 是数据库拆分的两种策略。它们在大规模数据库优化、分布式架构设计中至关重要，主要用于 降低单库压力、提高查询效率、支持高并发。

1. 垂直分库分表（Vertical Sharding）

概念

垂直分库 和 垂直分表 的核心思想是按业务模块或功能拆分数据库，即：

垂直分库（Vertical Database Partitioning）：将不同的业务模块拆分到不同的数据库中
垂直分表（Vertical Table Partitioning）：在同一个数据库中，将一个大表按字段拆分成多个表

示例

假设有一个 电商系统，包含 用户信息、订单、商品、支付 等功能，如果所有数据都存放在一个数据库 ecommerce_db，会导致：

单库压力过大
查询、写入效率下降
影响数据库扩展能力

可以采用 垂直分库：

user_db         → 存储用户信息
order_db        → 存储订单信息
product_db      → 存储商品信息
payment_db      → 存储支付信息

不同的业务数据存储在不同的数据库中，每个数据库只处理自己相关的业务，提高效率。

垂直分库 vs. 垂直分表

方式	说明	适用场景
垂直分库	按业务模块拆分数据库，每个库独立存储不同业务数据	业务数据相对独立，不同模块间交互少
垂直分表	在同一个数据库内，将大表按字段拆分成多个小表	单表字段过多，部分字段访问频率低

查询示例

查询用户信息：

SELECT * FROM user_db.users WHERE id = 1001;

查询订单信息：

SELECT * FROM order_db.orders WHERE user_id = 1001;

各个数据库可以独立扩展，互不影响。

优点

✅ 分担数据库压力：不同业务拆分到不同数据库，查询、写入性能提升
✅ 不同数据库可独立优化：如 user_db 读多写少，可优化为读写分离；order_db 写入频繁，可优化为高性能写库
✅ 支持不同存储策略：如 user_db 存 MySQL，payment_db 存 PostgreSQL

缺点

❌ 跨库 JOIN 复杂：无法直接执行 JOIN 查询，需要在应用层处理
❌ 事务一致性问题：跨库事务需要分布式事务（如 TCC、XA）
❌ 运维复杂：多个数据库管理、备份、迁移成本增加

2. 水平分库分表（Horizontal Sharding）

概念

水平分库分表 的核心思想是按照数据量进行拆分，即：

水平分库（Horizontal Database Partitioning）：将数据按某个分片键（Sharding Key） 均匀分布到多个数据库
水平分表（Horizontal Table Partitioning）：将数据按分片键分布到多个相同结构的表

示例

假设有一个 orders 表，存储1 亿条订单数据，直接查询会导致：

查询速度变慢
索引过大，影响性能
数据库写入压力过大

水平分库

可以按照 user_id % 4 进行分库：

order_db_0: user_id % 4 = 0
order_db_1: user_id % 4 = 1
order_db_2: user_id % 4 = 2
order_db_3: user_id % 4 = 3

查询用户订单：

SELECT * FROM order_db_2.orders WHERE user_id = 1002;

数据分布均匀，每个库的压力降低。

水平分表

在 order_db 内部，将 orders 表按 user_id % 10 拆分为 10 张表：

orders_0: user_id % 10 = 0
orders_1: user_id % 10 = 1
...
orders_9: user_id % 10 = 9

查询用户订单：

SELECT * FROM orders_2 WHERE user_id = 1002;

避免单表数据过大，提高查询速度。

水平分库 vs. 水平分表

方式	说明	适用场景
水平分库	按 `Sharding Key` 进行数据库拆分，不同数据库存储相同结构的数据	单库容量受限，分片键可均匀分布数据
水平分表	在同一个数据库内，将大表拆分为多个小表	单表数据量过大，查询变慢，索引维护困难

优点

✅ 单库压力减少：数据分布在多个数据库或表，查询、写入速度更快
✅ 读写性能提升：不同库可并行查询、写入，提高吞吐量
✅ 易于扩展：可以继续增加数据库或表，支持大规模数据存储

缺点

❌ 跨库查询复杂：需要 UNION ALL 或应用层合并
❌ 事务管理难度大：需要分布式事务，如 TCC、XA
❌ 数据路由管理：需要在应用层或 Sharding Proxy 进行数据分片管理

3. 垂直分库分表 vs. 水平分库分表

对比项	垂直分库分表	水平分库分表
拆分方式	按业务模块拆分	按数据量拆分
数据存储	每个库存储不同表	每个库存储相同表，但数据不同
适用场景	业务数据独立，如用户、订单、支付分开	单表数据过大，查询和写入性能受限
查询优化	业务查询独立，无需跨库查询	需要跨库合并查询
事务管理	业务间事务较少	可能涉及跨库事务，需分布式事务
运维难度	需要管理多个数据库	需要管理数据路由、分片规则
扩展性	适合业务扩展，但数据量不均衡	可水平扩展，适合大数据量场景