如何正确的进行数据的分库分表

如果数据多到一定程度，就需要分库分表来存储数据了，这个一定程度的判断也比较难，总体而言，

数据量上：MySQL数据库在500w-1000w的时候性能比较好，单张表达到2000W（如果服务器配置比较好的话）sql经过优化，数据量大，当频繁插入或者联合查询时，速度变慢,就需要分表了。

磁盘：如果一个数据库存储的数据比较多，一台服务器的磁盘就会成为瓶颈，这个时候，就需要考虑分库了

数据库链接：如果一个数据库实例的链接过多，很容易就达到服务的上限，这个时候就有必要进行分库分表，当然，也可以通过引入 Redis 缓存的形式，在前面挡一下，可以降低服务器的链接

分库分表大体有两种思路：

1.修改代码，让代码去链接对应的数据库查询对应的表。

常见分表、分库常用策略

平均进行分配hash(object)%N(适用于简单架构)，这个方式可能会遇到如果某个用户的数据过多，就会造成数据倾斜的问题。

 按照权重进行分配且均匀轮询，想法挺好，但是会增加代码的复杂度。

 按照业务进行分配，同上。

 按照一致性hash算法进行分配(适用于集群架构，在集群中节点的添加和删除不会造成数据丢失，方便数据迁移)。

2.采用数据库中间件，不调整代码也能实现分库分表功能，但是一般的中间件都会有这样或者那样的限制。

分库分表常用中间件

目前应用比较多的基本有以下几种，

• TDDL client 层方案
• Sharding-jdbc client 层方案
• Mycat proxy 层方案
• Cobar proxy 层方案

1、TDDL 

淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。

2、Sharding-jdbc

当当开源的，属于 client 层方案，目前已经更名为 ShardingSphere。SQL 语法支持也比较多，没有太多限制，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。

3、Cobar

阿里 b2b 团队开发和开源的，属于 proxy 层方案，就是介于应用服务器和数据库服务器之间。应用程序通过 JDBC 驱动访问 Cobar 集群，Cobar 根据 SQL 和分库规则对 SQL 做分解，然后分发到 MySQL 集群不同的数据库实例上执行。

4、Mycat

基于 Cobar 改造的，属于 proxy 层方案，支持的功能完善，社区活跃。

引入了这些中间件就会带来新的问题。如果是 修改代码 ，就会引入代码的复杂性，使代码变的复杂。如果是采用中间件，也是会引入问题，例如性能的降低，运维维护的成本，等等吧。肯定都不会那么如意。

那有没有更好的解决方案呢？

那肯定是有的，下面为大家介绍 腾讯云的TDSQL ：

TDSQL MySQL 版（TDSQL for MySQL）是腾讯打造的一款分布式数据库产品，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，同时提供智能 DBA、自动化运营、监控告警等配套设施，为客户提供完整的分布式数据库解决方案。目前 TDSQL 已经为超过500+的政企和金融机构提供数据库的公有云及私有云服务，客户覆盖银行、保险、证券、互联网金融、计费、第三方支付、物联网、互联网+、政务等领域。TDSQL MySQL 版亦凭借其高质量的产品及服务，获得了多项国际和国家认证，得到了客户及行业的一致认可。