前言：面试时的「脱口而出」
面试官：你用过哪些分库分表技术？
我：Sharding-JDBC、MyCat！
面试官：分布式服务怎么实现？
我：Spring Cloud、Dubbo！
但很少有人静下心来想：这些脱口而出的名词，从来都不是「技术本身」，而是「思想的落地工具」。
一、为什么说分库分表是「思想」，不是「技术」？
很多新手以为：配置了 Sharding-JDBC，把表拆成好几份，就是会分库分表了。
这就像：买了健身卡 = 拥有好身材？显然不是。
| 对比 | 健身 | 分库分表 |
|---|---|---|
| 工具 | 健身卡 | Sharding-JDBC、MyCat |
| 核心逻辑 | 坚持锻炼、科学饮食 | 把大数据拆小，分散压力 |
| 思想本质 | 健康生活 | 分而治之 |
真实场景：电商 APP 的噩梦
初期架构：一个 MySQL 实例，一个 ecommerce 数据库
| 表 | 数据量 |
|---|---|
| t_order（订单） | 2 亿条 |
| t_user（用户） | 1000 万 |
| t_goods（商品） | 几万条 |
问题来了：
- 查询用户历史订单：2 亿条里「大海捞针」，延迟飙到 3 秒以上
- MySQL 实例挂了：整个电商系统原地瘫痪
- 老板脸色：比锅底还黑
这时候，分库分表思想登场：核心就是「拆」，把大麻烦拆成小麻烦。
二、MySQL 实战：分库分表的 3 种落地姿势
思想核心：分而治之。但「怎么分」有讲究。
2.1 垂直拆分：按业务「分家」（专库专用）
思想：「物以类聚，人以群分」——孩子长大了要分家，各自过日子。
| 拆分方式 | 说明 |
|---|---|
| 垂直分库 | 按业务模块拆分数据库，放到不同 MySQL 实例 |
| 垂直分表 | 按字段频率拆分一张表，高频字段单独放 |
电商垂直分库示例：
| 数据库 | 包含表 | 专注业务 |
|---|---|---|
| db_user | t_user_base、t_user_ext | 用户信息查询/写入 |
| db_order | t_order、t_order_item | 订单高并发写入 |
| db_goods | t_goods、t_goods_stock | 商品查询/库存扣减 |
垂直分表示例：
t_user 有 50+ 字段，拆成两张：
| 表 | 字段类型 | 访问频率 |
|---|---|---|
| t_user_base | ID、手机号、密码 | 高频 ✅ |
| t_user_ext | 地址、头像、简介 | 低频 |
查询基础信息时，不用扫描多余字段，MySQL 效率翻倍。
避坑提醒：
垂直分库不是越多越好！别把「订单评价」单独拆库，数据量小、访问低，纯属没事找事。
2.2 水平拆分：按数据「分房间」（数据分片）
思想：一家人太多，一个房间住不下，就分多个房间。
核心逻辑： 一张大表 → 多张结构相同的小表
场景：订单表 t_order 2 亿条
按「用户ID哈希取模」拆成 8 张表：t_order_0 ~ t_order_7
// 分片规则
int tableIndex = user_id % 8;
// 示例
user_id = 1001 → 1001 % 8 = 1 → t_order_1
user_id = 2008 → 2008 % 8 = 0 → t_order_0
效果对比：
| 拆分前 | 拆分后 |
|---|---|
| 2 亿条单表 | 8 张 × 2500 万条 |
| 查询延迟 3s | 延迟 300ms 以内 |
避坑：千万别用自增ID当分片键！
| 错误做法 | 结果 |
|---|---|
| 用自增ID分片 | 新订单都挤到最后一张表 |
| 最后一张表暴增 | 其他表闲得发慌 |
| 相当于拆了房间，却只住一个 | 白忙活一场 |
时间范围拆分也很常用：
日志表按月份拆：t_log_202601、t_log_202602…
好处：
- 查询直接定位表，效率拉满
- 方便归档旧数据
2.3 混合拆分：分库 + 分表（应对超级大流量）
场景：千万级用户、亿级订单
拆分顺序：先垂直分库 → 再水平分表
| 步骤 | 操作 |
|---|---|
| 1 | 垂直分库：订单库 db_order 单独部署 |
| 2 | 水平分表：t_order 拆成 8 张表 |
| 3 | 再分库：8 张表分散到 db_order_0、db_order_1，各放 4 张 |
大厂高并发场景标配。
代价提醒：
拆分越多，复杂度越高：
- 跨分片查询
- 分布式事务
- 数据一致性
天下没有免费的午餐，想要高性能，就得接受复杂度。
三、分布式服务：另一种「解耦共生」的思想
分库分表是「拆分数据」，分布式服务是「拆分服务」。
核心相同：避免单点瓶颈，实现灵活扩展。
单体服务的噩梦
| 问题 | 说明 |
|---|---|
| 功能挤在一起 | 用户登录、下单、支付、商品查询大杂烩 |
| 一挂全挂 | 支付 bug → 用户登录也用不了 |
| 改一点全部署 | 改小功能，重新部署整个项目 |
| 运维成本离谱 | 高到离谱 |
分布式服务思想：解耦
把单体服务拆成多个独立小服务，各司其职，通过网络通信协同。
| 服务 | 职责 |
|---|---|
| 用户服务 | 用户登录、信息管理 |
| 订单服务 | 下单、订单管理 |
| 商品服务 | 商品查询、库存扣减 |
| 支付服务 | 支付处理 |
四、黄金搭档：分布式服务 + 分库分表
两者结合，才是高并发的「王炸组合」。
下单流程示例
用户点击下单
↓
订单服务接收请求
↓
调用用户服务 → db_user 查询用户信息
↓
调用商品服务 → db_goods 扣减库存
↓
订单服务 → db_order 分表写入订单（user_id % 8）
↓
调用支付服务 → 完成支付 → 更新订单状态
容错效果
| 某节点故障 | 影响 |
|---|---|
| 订单服务挂了 | 用户登录、商品查询正常 |
| 用户库崩了 | 订单写入、支付正常 |
| 订单分表满了 | 新增分表，不动其他服务和库 |
这就是「思想」的力量：让系统弹性、可靠、可扩展。
五、别再「本末倒置」
很多新手学分布式，死记硬背组件名：
| 组件 | 作用（比喻） |
|---|---|
| Nacos | 服务通讯录，让服务找到彼此 |
| Feign | 服务之间的电话，互相通信 |
| Eureka | 注册中心，服务发现 |
这些都是「工具」，核心是「解耦共生」的思想。就像手机打电话，手机是工具，「传递信息」才是目的。
六、总结：工具会过时，思想永不过时
| 内容 | 说明 |
|---|---|
| 分库分表 | 不是 Sharding-JDBC，思想是「分而治之」 |
| 分布式服务 | 不是 Spring Cloud，思想是「解耦共生」 |
| 核心竞争力 | 掌握思想，懂底层逻辑，新工具快速上手 |
记住：MyCat 过时了 → Sharding-JDBC；工具会变，思想不变。
彩蛋：别急着跟风
如果你的项目还是单体服务、单库单表：
先看数据量和并发量，真的扛不住了再拆。
就像房子小不用急着换别墅，适合自己的才是最好的。
本文链接： https://hyuzz-nuc.github.io/posts/database-sharding-distributed-service/
未经作者禁止转载！