现在经常说来水平扩展，这个时候一般都会说到数据库的水平扩展，这个时候一般就会用到数据库的分库分表方案。关于这一块，可能大家也都一些开源或商业的方案进行过一些研究。
今天我就简单的拿一些性能测试数据进行简单的展示，看看TinyDbRouter和Mycat与纯纯的JDBC之间的性能差异情况。
环境说明
为了进行这项测试，我就得准备一下测试环境，因为做的是对比测试，因此用多少NB的服务器不是重点。另外，由于虚拟机之间会有CPU、磁盘IO的资源竞争，因此我选择了用独立的计算机进行这项测试，这样才可以真正的模拟水平扩展时的硬件拓展方式。
为此我找了4台笔记本电脑，配置如下：
| 客户端和服务器 硬件配置： |
| 硬件平台：windows7旗舰版 （32位）物理机 |
| CPU： 4CPUs |
| 处理器：Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz |
| 内存：4GB |
| 硬盘：500G |
测试方案
这次主要测试多种方式下数据库的插入和查询方面方面的性能差异。
- 使用一个数据库，中间加一道分库分表中件间，然后测试直接使用JDBC和加一层中间件之间的性能对比，看看加了一层对性能的影响
- 使用两个物理数据库，对数据进行水平分片，然后测试直接使用JDBC操作一个库和用了中间件分成两个库之间的性能做对比
环境说明：为了更好的进行观察和分析，采用MyCat方式式，MyCat采用了独立部署为一台服务器的方式
测试数据
单个数据库增加TinyDBRouter访问时的插入性能影响
从上面的数据可以看到：在没有压力的情况下，在插入时增加了TinyDbRouter与不增加TinyDbRouter层时的性能对比为下降了6.6%，而在有压力的情况下性能下降大致为15%左右。
而在查询的时候，由于查询的时间较插入时间长许多，因此可以看到TinyDbRouter对于查询的影响可以忽略不计。
相同数据量采用TinyDbRouter分库的查询性能对比
从上面的数据可以看到，在没有压力的情况下，插入的速度较单库相比有些许下降，但是随着压力的增加，分片了的性能逐步上升，虽然压力没有加大到最大，但是处理性能已经是未分片的1.5倍左右，说明通过分片确实可以有效提升插入的TPS数量。
我们再来看看查询方面的性能差异，由于同样的记录数，分片方案中把数据均衡的分配到了两个不同的库中，因此不带分库键查询时，查询性能大致是未分库方式的2倍左右浮动（这里的查询条件是动态生成，因此刨除了缓冲方面的因素）；带有分库键进行查询时，查询性能大致是未分库方式的4倍左右浮动。
总结，通过分片的方式进行水平扩展，确实可以有效的提升插入和查询的效率。提升效率的多少与水平扩展的数量大致成正比。(实际上，随着分片个数的增加，每台机器的能力扩展系数是在慢慢减小的)。
相同数据量采用MyCat分库的插入性能对比
通过上面的测试，可以看到，使用 MyCat把数据分到两个物理数据库，也有效的提升了插入效率，这方面和TinyDbRouter的基本相同。
相同数据量采用MyCat分库的查询性能对比
接下来就是对MyCat的查询方面的性能进行对比测试，性能数据较不分库有一定提升，但是相对于TinyDbRouter就有一定的差距。
总结
不论是哪种分库分表方案，都可以有效提升插入和查询的TPS。
有分库键查询和没有分库键查询，性能相差明显。
TinyDbRouter和MyCat的数据库水平扩展中间件在插入方面的性能损耗相差不大，在查询方面TinyDbRouter的性能较MyCat有一定的优势，随着集群大小的变化，会导致性能的差距进一步扩大。
原因分析如下：
表明原因分析：MyCat服务器自已的CPU占有率比较高，说明其计算量也非常大，导致在MyCat服务器中产生了一定性能损耗。由于MyCat在这种测试方式下是单点，因此随着水平扩展的数据库数量的增加，其单点压力也会越来越大。
深层次原因分析：MyCat是由独立的服务器来进行查询及结果的合并及相关处理，因此必须把数据从数据库服务器取到MyCat服务器上进行一定的运算后再向客户端进行返回数据；而TinyDBRouter由于部署到数据库客户端，因此这部分计算由数据库客户端进行计算，充分的利用了数据库客户端的计算能力，因此不存在单点问题。
同样的一个处理，MyCat的方式是：客户端->MyCat->Mycat计算后->水平扩展的数据服务器(这里是2)->MyCat合并结果后->客户端
而TinyDBRouter的方式是：客户端->（DBRouter计算后）->水平扩展的数据服务器(这里是2)->（DBRouter计算后）->客户端，网络传输次数较MyCat少了一半。另外由于TinyDBRouter的合并计算在客户端进行，因此可以进行更深入的优化以提升数据获取速度。
声明
我们一开始把MyCat服务器和其中一台数据库服务器部署在一台物理机，结果数据非常不合常理，因此才把它独立部署为一台服务器。
我们一开始是用Delete语句清空数据的，后来发现这种方式对测试数据有比较大的影响，同样的数据量与测试方法，数据相去甚远。采用了DROP表现重建的方式后保证了数据的可验证性，同样的数据量与测试方式，数据非常接近。
我们在测试过程中，秉持了客观公正的心态来进行这项测试，也是为了找准自己的位置，和同类产品学习的态度进行的。
我们保证没有对测试数据进行任何的人为调整，而完全忠实于实验中采集的数据。
即使同样时刻的测试数据，也会有轻微的不同，但是差距非常小。