分库分表知识点

1、什么要分库分表？

一般一个表的数据最好控制在200万以内，一个库最多支撑并发2000，并发最好保持在1000。

#	分库分表前	分库分表后
并发支撑情况	MySQL 单机部署，扛不住高并发	MySQL从单机到多机，能承受的并发增加了多倍
磁盘使用情况	MySQL 单机磁盘容量几乎撑满	拆分为多个库，数据库服务器磁盘使用率大大降低
SQL 执行性能	单表数据量太大，SQL 越跑越慢	单表数据量减少，SQL 执行效率明显提升

 

2、不同的分库分表中间件都有什么优点和缺点？

Sharding-jdbc：是client层方案，优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高。缺点是各个系统都需要耦合Sharding-jdbc的依赖。

Mycat： 是proxy层方案。优点是与业务系统解耦。缺点在于需要部署，自己运维一套中间件，运维成本高。

 

3、如何对数据库如何进行垂直拆分或水平拆分？

水平拆分：就是将数据均匀放更多的库里，然后用多个库来扛更高的并发，还有就是用多个库的存储容量来进行扩容。

垂直拆分：就是把一个有很多字段的表给拆分成多个表，或者是多个库上去。一般来说，会将较少的访问频率很高的字段放到一个表里去，然后将较多的访问频率很低的字段放到另外一个表里去。

两种拆分方式：

range 来分，好处在于说，扩容的时候很简单，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了；缺点，但是大部分的请求，都是访问最新的数据。实际生产用 range，要看场景。

hash 分发，好处在于说，可以平均分配每个库的数据量和请求压力；坏处在于说扩容起来比较麻烦，会有一个数据迁移的过程，之前的数据需要重新计算 hash 值重新分配到不同的库或表。

4、如何设计才可以让系统从未分库分表动态切换到分库分表上？

停机迁移方案：

双写迁移方案：

 

5、如何设计可以动态扩容缩容的分库分表方案？

第一次分库分表就给够，建32个库，32个表，一共1024张表。id%32取模到库，id/32%32取模到表。

刚开始可能一个MySQL服务器建了32个库，后面拆分DBA就不断在库和MySQL服务器之间做迁移就可以了。

1. 设定好几台数据库服务器，每台服务器上几个库，每个库多少个表，推荐是 32 库 * 32 表，对于大部分公司来说，可能几年都够了。
2. 路由的规则，orderId 模 32 = 库，orderId / 32 模 32 = 表
3. 扩容的时候，申请增加更多的数据库服务器，装好 MySQL，呈倍数扩容，4 台服务器，扩到 8 台服务器，再到 16 台服务器。
4. 由 DBA 负责将原先数据库服务器的库，迁移到新的数据库服务器上去，库迁移是有一些便捷的工具的。
5. 我们这边就是修改一下配置，调整迁移的库所在数据库服务器的地址。
6. 重新发布系统，上线，原先的路由规则变都不用变，直接可以基于 n 倍的数据库服务器的资源，继续进行线上系统的提供服务。

 

6、id 主键如何处理？

UUID：优点是本地生成，不基于数据库；缺点是UUID占用空间大，作为主键性能差；不具有有序性，会导致B+树索引写的时候有过多随机写操作，不能产生有顺序的append操作，需要进行insert操作，会导致读取整个B+数节点到内存，插入后回写磁盘，导致性能下降。

snowflake算法：一个 64 位的 long 型的 id

• 1 bit：不用，为啥呢？因为二进制里第一个 bit 为如果是 1，那么都是负数，但是我们生成的 id 都是正数，所以第一个 bit 统一都是 0。
• 41 bits：表示的是时间戳，单位是毫秒。41 bits 可以表示的数字多达 2^41 - 1 ，也就是可以标识 2^41 - 1 个毫秒值，换算成年就是表示69年的时间。
• 10 bits：记录工作机器 id，代表的是这个服务最多可以部署在 2^10 台机器上，也就是 1024 台机器。但是 10 bits 里 5 个 bits 代表机房 id，5 个 bits 代表机器 id。意思就是最多代表 2^5 个机房（32 个机房），每个机房里可以代表 2^5 个机器（32台机器）。
• 12 bits：这个是用来记录同一个毫秒内产生的不同 id，12 bits 可以代表的最大正整数是 2^12 - 1 = 4096 ，也就是说可以用这个 12 bits 代表的数字来区分同一个毫秒内的 4096 个不同的 id。