常见分库分表中间件技术选型

小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

前言

要不要分库分表？要不要选用NoSQL数据库做替换，在每做出一次技术架构选择的过程中，都是需要做综合的考量。虽然NoSQL 数据库发展非常快，性能也越来越高，但是带给程序员和运维的学习和维护成本也越高。

关系型数据库凭借其稳定、查询灵活、兼容等特性，仍被大多数公司作为首选数据库。所以分库分表应对海量数据和高并发对数据库的冲击，是各大互联网公司不可避免的问题。

一张MySQL数据数据量一般不能超过2000万，超过这个值会带来索引树的深度增加导致查询写入的性能下降。 比如电商的场景查询个人的订单信息，时间太长导致用户体验巨差。

分库分表场景

一般互联网应用两个场景垂直拆分和水平拆分 垂直拆分就是分多个库， 水平拆分顾名思义是同一个库拆分多张表。

常见的分库分表中间件

中间件	分库	分表	ORM框架支持	异构语言
Cobar（MyCat）	有	无	任意	可以
Cobar-Client	有	无	仅Mybatis	java
TDDL	未开源	未开源	任意	java
Sharding-JDBC	有	有	任意	java

目前常用的就是Cobar（MyCat）与Sharding-JDBC两种方案。

Cobar（MyCat）属于中间层方案，在应用程序和MySQL之间搭建一层Proxy。中间层介于应用程序与数据库间，需要做一次转发，而基于JDBC协议并无额外转发，直接由应用程序连接数据库，性能上比较好。

Cobar-Client、TDDL和Sharding-JDBC均属于客户端直连方案。此方案的优势在于轻便、兼容性、性能以及对DBA影响小。其中Cobar-Client的实现方式基于ORM（Mybatis）框架，其兼容性与扩展性不如基于JDBC协议的后两者。