MySQL 分库分表：数据库的"豪宅改造计划" ️

当你的单身公寓住不下所有家具时，你会怎么做？搬到大房子或者拆分成多个小仓库！MySQL 的数据也有同样的烦恼...

什么是分库分表？🤔

分库分表是指将原本存储在单个数据库和单张表中的数据，按照特定的规则切分到多个数据库或多个表中，以解决海量数据存储和访问的性能问题。简单来说：当数据量太大，一个"房子"住不下时，要么买更多房子(分库)，要么在同一个房子里隔出更多房间(分表)。

为什么要"搬家"？

场景：拥挤的公寓
数据库："我实在太拥挤了，每次查询都要翻箱倒柜！"
DBA："是时候搬家或者做个大扩建了！"
开发者："但搬家好麻烦啊..."
DBA："比你的系统崩溃容易处理多了！"

主要原因：

• 单表数据量过大 - 一张表超过千万级别，查询性能急剧下降
• 并发访问压力大 - 一个 MySQL 实例扛不住高并发
• 存储容量受限 - 单机硬盘总有极限
• 备份恢复时间长 - 几百 G 的数据备份一次要到天亮

分库分表的两大流派

1️. 垂直拆分 - "按功能区分不同的房子"

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"

垂直分库

做法：按业务模块将不同表拆分到不同的数据库中
案例：用户库、订单库、商品库分开部署

搬家前：
┌────────────────────┐
│    大杂烩数据库      │
│ ┌──────┐ ┌──────┐  │
│ │用户表 │ │订单表 │  │
│ └──────┘ └──────┘  │
│ ┌──────┐ ┌──────┐  │
│ │商品表 │ │评论表 │  │
│ └──────┘ └──────┘  │
└────────────────────┘

搬家后：
┌──────────┐  ┌──────────┐  ┌──────────┐
│  用户库   │  │  订单库   │  │  商品库   │
│ ┌──────┐ │  │ ┌──────┐ │  │ ┌──────┐ │
│ │用户表 │ │  │ │订单表 │ │  │ │商品表 │ │
│ └──────┘ │  │ └──────┘ │  │ └──────┘ │
└──────────┘  └──────────┘  └──────────┘

垂直分表

做法：将一张表中的列分拆到多张表，常用字段放一起，不常用字段另开表
案例：商品基本信息表、商品详细描述表、商品图片表

分表前：
┌─────────────────── 商品表 ───────────────────┐
│ ID │ 名称 │ 价格 │ 库存 │ 详细描述 │ 图片URL集  │
└─────────────────────────────────────────────┘

分表后：
┌─────── 商品基本表 ──────┐  ┌── 商品描述表 ──┐  ┌── 商品图片表 ───┐
│ ID │ 名称 │ 价格 │ 库存 │  │ ID │ 详细描述  │  │ ID │ 图片URL集 │
└───────────────────────┘  └───────────────┘  └───────────────┘

2️. 水平拆分 - "同样的房子造多个小区"

场景：小区扩建
开发商："一个小区住不下这么多人，我们再建5个一模一样的！"
居民："新小区和旧小区户型完全一样，只是地址不同！"

水平分库

做法：同一个表的数据拆分到不同数据库中
案例：订单库 1、订单库 2、订单库 3...

分库前：
┌────── MySQL实例 ──────┐
│         订单库         │
│     ┌───────────┐     │
│     │  订单表    │     │
│     │(1千万数据) │     │
│     └───────────┘     │
└───────────────────────┘

分库后：
┌─── 实例1 ───┐ ┌─── 实例2 ───┐ ┌─── 实例3 ──┐
│  订单库1    │ │  订单库2     │ │  订单库3   │
│ ┌───────┐  │ │ ┌───────┐   │ │ ┌───────┐ │
│ │订单表  │  │ │ │订单表  │   │ │ │订单表 │  │
│ │(300万)│  │ │ │(400万) │   │ │ │(300万)│ │
│ └───────┘  │ │ └───────┘   │ │ └───────┘ │
└────────────┘ └─────────────┘ └───────────┘

水平分表

做法：同一个数据库中的表拆分成多个表，结构完全相同
案例：订单表_0、订单表_1、...、订单表_9

分表前：
┌────────── 订单表 ─────────┐
│ order_id │ user_id │ ... │
│   10001  │  2103   │ ... │
│   10002  │  5832   │ ... │
│    ...   │   ...   │ ... │
└──────────────────────────┘

分表后：
┌── 订单表_0 ─┐ ┌── 订单表_1 ─┐     ┌── 订单表_9 ─┐
│id │user│...│ │id │user│...│ ... │id │user│...│
│...│ .. │...│ │...│ .. │...│     │...│ .. │...│
└────────────┘ └────────────┘     └────────────┘

分片策略："如何决定谁住哪儿" ️

1. 哈希分片 - "按门牌号分配"

应用："订单1234应该放在哪个库？"
路由层："1234 % 4 = 2，所以放在2号库！"

特点：

• 均匀分布数据
• 扩容麻烦，需要 rehash
• 不适合范围查询

2. 范围分片 - "按街区划分"

应用："ID为80万的用户应该放哪里？"
路由层："50万~100万的用户在2号库，所以放2号库！"

特点：

• 扩容简单
• 数据分布可能不均
• 适合范围查询

3. 时间分片 - "按入住日期划分"

应用："2023年1月的订单要查哪里？"
路由层："查订单_202301表就行了！"

特点：

• 历史数据归档方便
• 新数据集中在最新表
• 适合按时间查询

4. 列表分片 - "VIP 客户走专属通道"

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"
0

特点：

• 按特定业务属性分片
• 适合有明显区分的业务
• 数据分布不均

同构 VS 异构：房子风格不同了 ️

1. 相同表结构(同构)

所有分片表结构完全相同，就像同一个小区的不同楼栋。

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"
1

2. 不同表结构(异构)

分片后表结构有差异，就像别墅区和普通住宅区。

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"
2

分库分表的"搬家难题"

1. 分布式事务 - "多个房子的装修需要统一协调"

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"
3

解决方案：

• 柔性事务（最终一致性）
• XA 事务
• 消息队列

2. 跨库关联 - "朋友分别住在不同小区"

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"
4

解决方案：

• 冗余字段（反范式化）
• 数据字典表
• 应用层组装

3. 全局唯一 ID - "不同小区门牌号不能重复"

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"
5

解决方案：

• UUID
• 雪花算法(Snowflake)
• 集中式 ID 生成器
• 号段模式

4. 动态扩容 - "小区不够住了还要加新楼"

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"
6

解决方案：

• 一致性哈希
• 双写过渡
• 数据迁移工具

常见分库分表中间件

就像搬家公司，它们帮你处理复杂的路由和迁移：

1. Sharding-JDBC - 轻量级 Java 框架，像个小型搬家团队
2. MyCat - 强大的中间代理，像个专业搬家公司
3. DynamoDB - AWS 提供的全托管方案，像个帮你包办一切的豪华搬家服务
4. Vitess - YouTube 开源的可扩展 MySQL 集群系统，像个大型物流集团

分库分表最佳实践

1. 先分表后分库

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"
7

就像先在自家隔出更多房间，实在不行再买新房子。

2. 避免过度设计

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"
8

小别墅住 3 个人，没必要隔出 10 个房间。

3. 尽量避免跨库 JOIN

场景：家庭空间规划
家长："厨房用品放厨房，卧室用品放卧室，不要混在一起！"
数据表："我们按业务功能分开住，互不干扰！"
9

朋友住不同小区，就别老想着办集体 party 了。

"数据库就像是你的房子，当东西太多时，你有两个选择：买更大的房子，或者更好地整理现有空间。分库分表是整理的艺术，而不仅仅是简单地买更多房子。"

—— 匿名架构师

下次面试官问你 MySQL 分库分表，别慌！告诉他：那不过是数据库世界的"乔迁新居"罢了！