Mycat2 单库分表（一）：准备

1、场景

单库分表的场景其实很常见，以前我们做系统，如果一张单表数据量超过了1000万，即便加了索引，查询就会比较慢了，如果很不巧，有个查询还需要join，那就完了，估计查询效率可以直接让用户奔溃吧，而且在查询的时候，大概率数据库会出现拒绝写入的情况，那就是事故了。以前遇到这种情况，我们通常会采用历史表的方案，即把数据量大的表，搞出来个历史表，写个定时任务，每天或者每周第一天凌晨跑个批，把实时表的数据挪到历史表里面去，查询的时候告诉用户实时表里只存了最近一周或者一个月的数据，要查看历史数据，请移步历史数据查询。再进一步的，可以搞出来多个历史表，按照年份月份分一分，每个表的数量就都下去了，然后优化查询，索引啥的，问题就基本解决了。(这个做法十年前的方案吧)

但是，这种方案，有许多弊端，比如要写专门的分表操作的工具，再比如，需要针对该表进行查询优化，等等.......其实，最大的问题就是对于程序员来说，就是无法只关注业务本身，还需要对数据库进行相应开发。运维人员没有太多的处理空间，对于查询慢，链接占用之类的，也就只能做做索引啥的。工种之间的耦合程度太高了。

优化的另一个方案，就是增加冗余字段，把原来查询需要左右连接的地方，全都都搞成冗余字段，最好查询做单表查询，单表1000万的量企业也极限了，解决不了最终问题。

2、mycat基本原理

对不小中型项目，最好的方案是如果代码没啥大问题，最好别改了，毕竟已经上线了，再折腾，程序员也不太愿意。目前我采用的方案是使用mycat分库分表操作。具体的原理网上很多，不多做赘述。总结起来一句话，mycat中间件，负责分库分表插入、查询、事务的具体工作，对外提供一个逻辑库和逻辑表，对于程序来说和原来一样，并没有什么变化。对于实际上的物理库来说，增加了分库分表的相关表。

3、再说一下选择mycat1.6还是mycat2.x

关于mycat1.6和2.x版本的对比，官网上有，也挺详细的，大家可以自己参考，我这里想说一点注意的，就是官网上对比的第一条，是否支持多语句，1.6不支持，2.x支持，这个一定要注意。我之前做配置的时候，因为想熟悉基本的原理，以及本能的想，1.6肯定稳定一点，2.x还在发展，所以先从1.