- 分库
- 解决什么问题:
- 如何做?
- 水平分库
- 垂直分库
- 分表
- 解决什么问题
- 如何做
- 水平分表
- 垂直分表
- 分库分表的问题(分库分表带来的问题)
- 1. 数据不均衡
- 2 跨库事务
- 3 唯一键
- 4. 跨库查询
- 5. 热点问题
分库
- 将一个数据库拆分成多个数据库
解决什么问题:
- MySQL实例分配的磁盘有限,
- 单库的存储容量有限。如果一个库存储的数据量超出单机磁盘或文件系统的承载上限（如 ext4 的单文件 2TB 限制）,超过会写入失败(我没试过,你们可以试试)
- 单 MySQL 连接上限的问题(最大 1万多,一般最多设置 5-6k)
- 其他
- 性能严重下降(就像手机空间小了容易卡顿,可能是磁盘拿来当内存使(扩容);数据量大,加载的数量多,磁盘 io 增加,变慢)
- 容易崩溃(卡死)
- 备份与恢复漫长
如何做?
水平分库
- 分摊数据量: 将数据库中的数据分摊到多个库
- 具体做法: 对数据的 id(或者其他的字段)哈希取余,然后决定储存到那个数据库中
垂直分库
- 将数据库根据业务进行拆分
- 不同业务使用的表放到不同的数据库中
- 比如(用户库存放用户信息,商品库,订单库)他们对应不同的功能.
- 这样 1 可以分摊请求压力,2 可以做隔离
分表
解决什么问题
- 查询性能低(主要是全表扫描)
- 写入性能低(b+树的平衡机制)
1000 万与两亿数据读写对比
- 全表扫描查询一条数据
- 1000 万耗时 2s;
- 两亿:耗时 40s
- 写 10 万条数据耗时
- 1000 万 2-3 秒
- 两亿: 20-30 秒
一个查询执行太久会导致有大量的连接被占用,达到连接上限就会报错.
如何做
水平分表
- 让一个数据表的数据行数变少,查询时间变快
- 具体做法: 对数据的 id(或者其他的字段)哈希取余,然后决定储存到那个数据表中
垂直分表
- 让每行数据所占空间变少,减少 io 的次数(MySQL 一次 io16k)
- 根据不同字段的功能特点进行分表
- 比如: 用户表有 50 个字段,可以根据信息的特点分成基本信息与拓展信息
- 这样可以减少查询的磁盘 io 次数,降低查询耗时.
分库分表的问题(分库分表带来的问题)
1. 数据不均衡
- 比如两个数据库,取余大部分数据(80%)都是一个数据库中的怎么办?
2 跨库事务
分库后，数据可能分布在不同的库中。例如：
一个订单系统，订单信息和用户信息被拆分到不同的库。如果需要在一个事务中同时更新订单状态和用户余额，就涉及跨库事务。
3 唯一键
对表/库进行水平拆分后就无法保持强唯一约束了
- 解决方案
- UUID：
使用 UUID 生成唯一标识。
优点：保证全局唯一；缺点：UUID 长度大，索引性能较差。
- 雪花算法：
基于时间戳生成全局唯一 ID（如 Twitter 的 Snowflake 算法）。
优点：高效，生成的 ID 有序；缺点：依赖外部服务。
- 数据库自增步长：
设置每个库的自增 ID 起始值和步长。例如：
库1：1, 3, 5…
库2：2, 4, 6…
优点：实现简单；缺点：不适用于动态扩容。
4. 跨库查询
问题
分库后，复杂查询（如多表 JOIN 或聚合操作）变得困难。例如：
查询某用户的所有订单和支付记录，但订单和支付信息在不同库中。
5. 热点问题
分库分表可能导致数据访问集中于某些分片。例如：
用户按 ID 分片，但某些大客户的操作频繁集中到一个库，造成热点
参考:
https://cloud.tencent.com/developer/article/1901963
https://www.cnblogs.com/chengxy-nds/p/16924305.html
https://cloud.tencent.com/developer/article/1843987
