DataBase分库分表策略

对应一个在IT行业，摸爬滚打近十年的秃头程序猿来说，对这个行业的数据库有一些自己的认识。

下面我介绍一下个人理解，如果各位有更好的idea可以在以下留言，博主非常愿意倾听各位的指导意见。

对于我这个接触了大型国家电网行业及物联网，跨境电商行业（进口）的码农来说，数据存储并不陌生。

小到字节，字符，文件导入导出，数据库数据存储。

下面就数据库存储做一些自我的讲解：

在跨境电商行业工作随时间的迁移，对于数据存储有一些瓶颈，从单机版到微服务，单库存储已经没有办法满足业务的需要。

因此数据库的分库分表显得不再陌生，mysql的分库分表可以大概从以下几个方面考虑，后面要讲解的大概是包括以下几个点展开：

1.跨境电商网站（app,mobile,小程序等）发展过程常有的问题

2.数据库及数据表的拆分方式及区别

3.目前开源的产品，技术的优越点

4.什么方式拆分数据库及表更优

在互联网发展过程中，单机版是我们最先接触也是开发效率在早期零几年最先接触的一种开发方式或者实现方式，但是随着互联网发展，及互联网节日的到来6.18，双11.11,双12.12的灯活动，互联网数据并发量问题的出现，让我们不得不考虑互联网瓶颈的到来我们应该如何应对，当我们在考虑这些的时候，大佬们已经为我们做了很多实现的方案，

如：

硬件的拆分随业务扩展，这个不是本次讲解的重点，忽略；

分布式服务，按模块进行开发;【dubbo】

微服务方式，按业务（一个服务处理一个事情），进行开发；【springBoot,springCloud】

开发方式层出不穷，那么数据库压力也随之而来，对于跨境电商来说，上百万千万级数据并非，单库的磁盘空间数据存储能力，数据库处理能力，单数据库的IO操作瓶颈。

因此后面越来越多的海量数据，在我们单机版，简单的数据主从复制已经没有办法满足我们的需要，从库数据同步更新主库数据保持一致性，从库的水平扩展，以致于造成更多的请求不成功的问题。

这个时候我们就需要两个以至于更多的master主库直接进行同步，也就是相当于数据重复更加复杂了。

分库分表：

1.用户请求量庞大

单服务器的TPS(吞吐量)，内存，IO限制。方案：分散请求到不同服务器，用户请求执行的脚本本质不变，请求同一个资源，只是请求会经过不同网关，路由，http服务器。

2.单库太大

单个数据库处理能力有限，单库所在服务器的磁盘空间不足，单库上的IO操作瓶颈。方案:拆分城更小的数据库

3.单表太大

索引膨胀，查询超时，CRUD都成问题。方案：切分成多个数据集更小的表。

分库分表的方法

一般有两种方式:垂直拆分和水平拆分，这个是物理上的拆分方式，针对不同问题进行解决。用户量请求大：就用物理机器的堆来处理，此处忽略。

垂直拆分

1.垂直分表，大表拆小表，基于字段多到少，常用及不常用进行差分，比如上百列的大表，避免查询时，数据太大，跨页问题。

2.垂直分库，按照业务进行拆分，分别部署不同的服务器

水平拆分

1.水平分表，RANGE，HASH,但是数据表在同一个库中，数据库IO瓶颈无法解决，不建议使用。

2.水平分库分表，单表数据拆分到不同服务器上面去，每个服务器具有相应的数据库和表，数据集合不同，缓解单机和单库的瓶颈，压力，突破IO，连接数，硬件资源瓶颈。

3.水平分库分表切分规则，A.RANGE B.HASH取模 C.地理区域（华东，华北，华南） D.时间（半年，一年旧数据【冷热数据分离】）

数据库分库分表面临问题

事务支持

多苦结果集合并（group by，order by）

TODO

跨库join

分库分表方案产品，推荐Cobar

附图：网络推荐