如何权衡分库分表中的Client与Proxy实现，在性能与维护性之间做出最优选择？

本文共计1556个文字，预计阅读时间需要7分钟。

家庭和睦，我是【架构布局师】，一位十年的程序猿。这是数据库分表系列的第一篇文章，这个系列将和大家分享很多在实际工作中实用的经验。如有收获，请分享给更多朋友。其实“

大家好，我是，一只十年的程序猿。这是分库分表系列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。

其实这个系列有录过视频给大家学习，但很多读者反馈说看视频太慢了。也不好沉淀为文档资料，希望能有一系列文字版本的讲解，要用的时候可以快速浏览关键的知识点。那么它就来了，我再花点时间写成几篇连续的文章供大家学习。

分库分表的手段 手动路由

如果没有复杂的操作，手动路由相对来说是简单的方式。比如你的操作只根据分片键操作，那么通过分片键你可以计算出这条数据的库和表，从而将你的SQL路由到指定的库进行执行。

这里主要是要在执行SQL的时候，动态获取对应的数据源，获取到数据源之后就用这个数据源进行SQL的执行。至于SQL在哪张表即SQL拼接的时候就已经知道了。

这也是最简单的实现分库分表的方式，但是实际业务中，我们不可能只根据分片键进行查询，假设有非分片键的查询，就还涉及到数据聚合，分页的问题，如果每个业务都要自己处理，这复杂度就太高了，所以我们需要一款中间件来支撑分库分表的需求。

中间件

分库分表中间件的出现，降低了分库分表的门槛，也极大的提升了开发效率。中间件内部会回SQL进行校验，解析，路由，聚合等逻辑。同时也会考虑到可用性，易用性等方面。

目前中间件主要分为两种类型，一种是Client方式的中间件，比如Sharding-JDBC，Ctrip DAL，TSharding等优秀的中间件。

一种是Proxy方式的中间件，比如ShardingSphere，Mycat等优秀的中间件。