mysql存放超过几百万条数据后就有了性能问题
互连网应用：大多都是读多写少
垂直分库
将一个数据库按照业务分类拆分为多个数据库。比如订单的、会员的、商品的、用户的、后台的、、
垂直分表
有的业务场景下不需要用户的所有信息，不需要查询所有字段
将用户的部分信息拆分出来到子表中
总结
每个库（表）的结构都不一样
每个库（表）的数据都（至少有一列，通常是记录 id）一样
每个库（表）的并集是全量数据。因为是从原来的库（表）进行拆分的，同理也可以合为全量数据。
优点：
拆分后业务清晰（专库专用按业务拆分，隔离性好）
便于维护数据
缺点：
受某种业务来决定、或者被限制。一个业务往往会影响到数据库的瓶颈（性能问题）。比如果双11，订单的业务操作量很大，此时会限制其他业务的使用。
部分业务无法关联。比如垂直分库中不同的数据库的表无法关联（join），只能通过 java 程序接口去调用，提高了开发复杂度。
水平分库
创建 10 个表，假设每个表最多存放 500 w条数据，根据用户 id 的最后一位决定使用那张表。 这样容量从原来的 500w 扩充到了 5000w。试想，随着业务规模扩大，总数据量超过 5000w，怎么做？
水平分表
分页怎么做？
每个库（表）的结构都一样
每个表的数据都不一样
每个库（表）的并集是全量数据
单库（表）的数据保持在一定的量（减少），有助于性能提高
提高了系统的稳定性和负载能力。
分出的表的结构相同、程序的改造比较小。每个表记录都用 pojo 存储，当表字段改动时，根据业务进行垂直拆分的表需要改动的 pojo 类更多，而垂直拆分因为所有表都用一个结构，修改的 pojo 类较少。
数据扩容有难度。每个库或表的存储能力都有上限，当最初水平拆分的表或库存满后，扩容很困难。
垂直拆分：按字段进行拆分。少表多字段拆成多表少字段。
水平拆分：按照数据（内容）拆分。比如 id 尾号为 1 放在 <code>db_1</code> 库，id 尾号为 2 放在 <code>db_2</code> 库、、
前期垂直拆分，后期水平拆分。
前期主要做业务的拆分，分库更加直观
后期主要做数据的拆分。
增加了开发成本和维护成本。相比于单表单库来说。。
跨库join查询。
分布式事务。原来的 acid。。
分布式全局唯一 id，需要使用程序设计 id
<code>mycat</code>、<code>shardingsphere</code>、<code>tddl</code>、<code>mysql-proxy</code> 等等
分类：
jdbc 应用层。<code>shardingsphere</code>、<code>tddl</code>。在程序中实现
proxy 代理层。<code>mycat</code>、<code>mysql-proxy</code>。
jdbc 应用层分片，代表 <code>shardingsphere</code> （之前叫 <code>sharding-jdbc</code>） ，底层原理：
以前的 shardings-jdbc 是基于 jdbc 的，只能通过 java 语言使用 目前支持 proxy分片 https://shardingsphere.apache.org/index_zh.html github：https://github.com/apache/shardingsphere
proxy代理层分片，<code>mycat</code>
比较：
jdbc应用层分片
性能好
支持跨数据库。
增加了开发难度。需要依赖 jar 包，需要修改配置
只支持 java 语言使用。
proxy代理层分片
可供多种语言使用。python、c、php、、、
开发无感知。逻辑在代理层实现，对程序员开发要求降低，不用关心背后的节点，开发只用面向代理层，像一个黑盒子。
性能下降。增加了代理层，增加了数据传递次数
只支持 mysql，不支持 oracle。
https://www.bilibili.com/video/bv1pq4y1r7fv?p=1
博客：
javascript:void(0)
沉舟侧畔千帆过，病树前头万木春。