Mysql分库分表方案-上

本文探讨了数据库因压力而进行分库分表的必要性,详细解释了分库分表的原因,包括链接数限制、写压力和主从同步延迟。同时介绍了sharding-sphere、TDDL等分库分表工具及其优势,如动态数据源管理和读写分离。分库分表的原则强调尽量避免切分并减少跨库Join,通过数据冗余或表分组降低复杂性。此外,文章还提出了分库分表过程中需解决的分布式ID问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、分库分表背景

1. 为什么分库

瓶颈来自数据库的压力:链接数,写压力且写查询高时主从同步延时。至于为什么会延时,可以参考下图:

如图:其中从库是一个线程异步去拉取,且从relay Log 到slave Database 也是需要顺序读到语句之后 进行随机的磁盘读写,也会延时。

2. 为什么分表

有一组数据可以参考:
基本指标:
库物理文件大小<100G;表<100;字段<200 ;单表记录数<500W
经测试在单表1000万条记录以下时,写入读取性能是比较好的. 这样在留点buffer,那么单表全是数字类型的保持在800万条记录以下, 有字符型的单表保持在500万以下。当预估业务单表数据量大,或是已经出现查询慢等情况,考虑分表。

二、目前有哪些分库分表工具

  1. sharding-sphere:jar,前身是sharding-jdbc;
  2. TDDL:jar,Taobao Distribute Data Layer;
    主要的好处
    ⅰ. 数据库主备和动态切换
    ⅱ. 带权重的读写分离
    ⅲ. 单线程读重试
    ⅳ. 集中式数据源信息管理和动态变更
  3. MTDDL (集成了 分布式ID生成系统Leaf)
  4. Mycat:中间件

TODO:具体区别对比

三、原则:

1 能不切分尽量不切分
2 数据切分尽量通过数据冗余或表分组来降低跨库 Join 的可能。比如:

在这里插入图片描述
上表里每一条记录,都记录了我的粉丝是谁这个信息。现在对这个表进行分库操作的话,假如按照用户维度分库,那同一个用户的粉丝一定都在同一个库里,但是如果查一个粉丝都关注了哪些人,那就需要查询所有的库。这个时候分析这种场景如果是很常见的话,那可以再按照粉丝维度分库,即我们常说的 「空间换时间」

四、主要考虑的问题

1.分布式ID 问题

分库分表首先要解决的就是分布式唯一主键的问题
下次我们谈下这个问题==

参考:
https://zhuanlan.zhihu.com/p/84224499
https://www.cnblogs.com/yb-ken/p/15623317.html
https://www.mashibing.com/study?courseNo=387&sectionNo=22376&activeIndex=0

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值