在扩展 MySQL 时，何时该用分区（partitioning）而非分片（sharding）？

Question

IT Interview Practice · Accepted Answer

两者都在拆分一张大表，但层级不同。**分区**在**单个 MySQL 服务器内部**把一张表拆分到多个文件。**分片**则把数据拆分到**多台相互独立的服务器**上。分区解决单个文件装不下的表；分片解决单台机器扛不住的工作负载。

## 分区（单服务器）

```sql
CREATE TABLE events (
  id BIGINT, created_at DATETIME, payload JSON,
  PRIMARY KEY (id, created_at)          -- 分区键必须出现在每个唯一键中
) PARTITION BY RANGE (YEAR(created_at)) (
  PARTITION p2024 VALUES LESS THAN (2025),
  PARTITION p2025 VALUES LESS THAN (2026),
  PARTITION p2026 VALUES LESS THAN (2027)
);
-- 按 created_at 过滤的查询只命中一个分区（分区裁剪 partition pruning）；
-- 删除旧数据只是瞬间完成的 ALTER TABLE ... DROP PARTITION p2024。
```

非常适合时间序列和便捷归档，但它仍是单台服务器 —— 总的 CPU、RAM 或写吞吐量并不会增加。

## 分片（多服务器）

选择一个**分片键（shard key）**（例如 `user_id`），通过哈希或范围把每一行路由到某个分片：

```
shard = hash(user_id) % N
  用户 42 -> 分片 2（服务器 B）     用户 99 -> 分片 0（服务器 A）
```

- **优点** — 写入、存储和连接数几乎能线性扩展。
- **缺点** — 跨分片的 JOIN 和事务很难甚至不可能；糟糕的分片键会造成热点；当你新增服务器时**重新分片（resharding）**非常痛苦。选一个高基数、分布均匀的键，并避免必须扇出到所有分片的查询。

## 操作顺序

先用尽更便宜的手段：建索引、查询调优、读副本、缓存，然后才是分区。只有当单个主库再也无法吸收**写入**量时，才动用分片 —— 它是运维复杂度上最大的一次跃升。

## 为什么这很重要

扩展决策在很大程度上不可逆且代价高昂。知道分区是单服务器的组织工具，而分片是一项分布式系统层面的承诺 —— 连同它的分片键与跨分片成本 —— 能让团队避免过早分片，也不会指望分区去解决它根本解决不了的写吞吐量上限。

分区（单服务器）

分片（多服务器）

操作顺序

为什么这很重要

相关问题