标签：常用 缓存 分布式 客户 频率 代理 服务端 支持 表结构
①分库分表说白了，就是因为数据量太大了，如果你的单表数据量都到了千万级别，那么你的数据库就无法承受高并发的要求，数据库操作性能就会出现极大的下降。
②数据库并发量太大了，一般而言，一个数据库最多支撑并发到2000，这时候一定要进行扩容，不然性能会出现严重下降。而且一个健康的单库并发值你最好保持在每秒1000左右，不要太大。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。
比较常见的中间件有cobar、TDDL、atlas、sharding-jdbc、mycat。
①cobar ：阿里b2b团队开发和开源的，属于proxy层方案。已经好几年没有进行更新了，基本没啥人用。而且不支持读写分离、存储过程、跨库join和分页等操作。
②TDDL :淘宝团队开发的，属于client层方案，不支持join，但是支持读写分离。目前使用的也不多，因为还依赖淘宝的diamond配置管理系统。
③atlas ：360开源的，属于proxy层方案，以前有一些公司在用，但是已经好几年没有更新了，所以现在用的也不多。
④sharding-jdbc ：当当开源的，属于client层方案。SQL语法支持多，没有太多的限制，从2.0版本开始支持分库分表、读写分离、分布式id生成、柔性事务(最大努力送达型事务、TCC事务)。而且现在使用较多。
⑤myCat ：基于cobar改造，属于proxy层方案，支持的功能完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。
①proxy类型
proxy类型的中间件就是一个客户端，需要直接部署一个中间件，去进行分库分表。服务端将sql发送到中间件客户端去进行不同表库的操作。如果中间件客户端不可用将直接导致无法进行分库分表，而且要走网络耗时。
②client
client不需要单独部署中间件客户端，运维成本低，中间件就是一个jar包，直接在项目中导入、配置就可以完成分库分表，而且不需要代理层的二次转发，性能高点，但是遇到升级等操作需要重新发布版本，各个系统都需要耦合sharding-jbdc的依赖。
①垂直拆分
垂直拆分的意思，就是把一个有很多字段的表给拆分成多个表，或者是多个库上去。每个库表的结构都不一样，每个库表都包含部分字段。一般来说，会将较少的访问频率很高的字段放到一个表里去，然后将较多的访问频率很低的字段放到另外一个表里去。因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。
这个其实挺常见的，不一定我说，大家很多同学可能自己都做过，把一个大表拆开，订单表、订单支付表、订单商品表。
②水平拆分
水平拆分的意思，就是把一个表的数据给弄到多个库的多个表里去，但是每个库的表结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据。水平拆分的意义，就是将数据均匀放更多的库里，然后用多个库来抗更高的并发，还有就是用多个库的存储容量来进行扩容。
③表的拆分
还有表层面的拆分，就是分表，将一个表变成N个表，就是让每个表的数据量控制在一定范围内，保证SQL的性能。否则单表数据量越大，SQL性能就越差。一般是200万行左右，不要太多，但是也得看具体你怎么操作，也可能是500万，或者是100万。你的SQL越复杂，就最好让单表行数越少。
一般来说，垂直拆分，你可以在表层面来做，对一些字段特别多的表做一下拆分；水平拆分，是并发承载不了，或者是数据量太大，容量承载不了，你给拆了，按什么字段来拆，你自己想好；分表，你考虑一下，你如果哪怕是拆到每个库里去，并发和容量都ok了，但是每个库的表还是太大了，那么你就分表，将这个表分开，保证每个表的数据量并不是很大。
①range方式
就是每个库一段连续的数据，这个一般是按比如时间范围来的，但是这种一般较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了。
range来分，好处在于说，后面扩容的时候，就很容易，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了；缺点，但是大部分的请求，都是访问最新的数据。实际生产用range，要看场景，你的用户不是仅仅访问最新的数据，而是均匀的访问现在的数据以及历史的数据
②hash方式
按照某个字段hash一下均匀分散，这个较为常用。
hash分法，好处在于说，可以平均分配没给库的数据量和请求压力；坏处在于说扩容起来比较麻烦，会有一个数据迁移的这么一个过程
标签：常用 缓存 分布式 客户 频率 代理 服务端 支持 表结构
原文地址：https://www.cnblogs.com/jack1995/p/10924453.html
