分库分表分析

场景：
随着公司的业务量的逐步增大，数据库的数据量也不断增加，达到百万、千万级别，甚至更多，这个时候发现传统方式的单库单表已经难以支撑业务发展，性能要求难以满足，查询耗时太久等问题，随时会导致系统奔溃。此时就需要考虑新的解决方案，一般都会想到进行分表分库之类的方法。

常见分库分表工具：
sharding-jdbc和mycat，其他的还有cobar、TDDL、atlas等。
sharding-jdbc：当当开源的，属于 client 层方案，sql语法支持比较好，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。sharding-jdbc不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合 sharding-jdbc 的依赖。
mycat：基于 cobar 改造的，属于 proxy 层方案，支持的功能非常完善，社区很活跃。mycat 需要部署，自己运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。

分库分表的几种方式：
水平分表：把同一个库中的一张表拆分成多个表，表结构完全一样，只是表数据不同，存放数据的时候通过算法将数据均匀地存在拆分的几个表中，解决单表数据量过大，提高查询效率。拆分的条件，单表数据量很大，但是没有达到数据库实例容量的2/3

水平分库：将同一个库中的表拆分成几个之后，查询性仍然无法满足，毕竟都还是在同一台服务器上，这个时候就可以进行水平分库了，根据规则将同一张表的数据根据业务规则放到不同的库里，这些库可以分布在不同服务器，从而使访问压力被多服务器负载，大大提升性能，解决了单库大数据，高并发的性能瓶颈。

垂直分表：根据字段的访问频率，将一个表按照字段分成多表，每个表存储其中一部分字段，查看微博内容与点赞量互不影响，充分发挥热门数据的操作效率，微博内容的操作的高效率不会被点赞量低效率所拖累，也避免IO争抢并减少锁表的几率。比如微博数据，有微博内容、点赞数、阅读量 ，可以由传统的一张表拆成3张表，内容表、点赞表、阅读量表。

垂直分库：进行垂直分表之后，性能问题任然还有问题，则可以将不同业务的表放到不同的库中，比如将微博内容表放到服务器1的库中，阅读量表放到服务器2的库中，点赞表放到服务器3的库中，实际上就是专库专用。


注意：分库分表可能解决了查询效率的问题，但也会带来一定的弊端。比如主键问题，事务问题等