一、分库分表背景

1. 为什么分库

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

mysql数据量一般多少的时候考虑分表 mysql分表数量取决于什么_mysql数据量一般多少的时候考虑分表

如图:其中从库是一个线程异步去拉取,且从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 的可能。比如:

mysql数据量一般多少的时候考虑分表 mysql分表数量取决于什么_spring_02


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

四、主要考虑的问题

1.分布式ID 问题

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