mysql分库分表思路

常用的切分方案

数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式。一种是按照不同的表（或者Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的垂直（纵向）切分；另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。
—————————————————————————————————

垂直切分（垂直分库 垂直分表）

• 纵向分库——根据业务耦合性， 将关联度低的表存放到不同数据库（和微服务思想类似）
  按业务功能分库，不同的业务：如业务本身相关表，工作流表，参数表各一个库。
• 纵向分表——按“列”分表，新建一张扩展表，将不常用的字段或者长度较大的字段拆分到扩展表中。
  按“列”拆分,大表变小表，防止数据过大导致查询数据时分页，降低性能。

优点:

• 业务划分清晰，易于扩展及维护，分级管理及监控。

缺点：

• 部分表没法join，只能依靠接口的聚合。提高了系统的复杂度。
• 需要维护多数据源。
• 需要处理分布式事务。
• 依然存在单表数据量过大问题。

由于垂直拆分是根据业务将表分散到不同的库，那么有些热点业务会造成数据过于庞大，这时候就需要水平拆分。

水平切分：（分库分表）

将同一个表按照不同的条件分散到不同数据库中。从而使得单个表数据变小。达到分布式的效果。
若仅仅是横向切分，可以理解为每个分片库中都可以拥有全生态的表，包括参数表，工作流表等等。只不过是热点业务表的数据被拆分到不同的库中。这种拆分方式，join操作基本可以操作数据库。但基本都是横向纵向交叉切分的。

优点：

• 不存在单库数据量过大的问题。
• 可以直接根据数据库分片键确定具体数据库。
• 整个系统的稳定性和负载能力得到提高。（毕竟水平扩展了这么多库呢。）

缺点：

• 拆分规则难以抽象。

对于业务数据两种常用的拆分规则：
方式一.依赖分片键（如订单号），对订单号取模，将数据落到不同的库中。缺点：横向扩展需要重新取模落表，数据需要重新迁移。
方式二.如果为用户，则根据uid，将0_{9999用户存到数据库1，将10000}19999的用户存到库2。
采用取模来确定分库键落哪张表，假如我要查询订单列表。势必要去各个分片库查找。这时候我们未使用分片键，无法定位到具体数据库，只能查找所有分片库。
采用按顺序分组的方法，将0_{9999用户存到数据库1，将10000}19999的用户存到库2。新用户比较活跃的，所以势必造成某某个数据库负载较大的问题。

• 分库，势必需要处理分布式事务，提升系统开发复杂度。
• 分库，万一需要join，性能势必较差。

纵向横向交错切分：

• 有时需要跨库进行join操作，性能很差。解决参考方案：1.需要用到jion的地方，增加冗余字段，尽量减少jion操作。2.全局表，将诸如“字典数据表”这种很少变动的表在每个分片库中都存一份。3.应用层面的数据组装。4.将存在关联关系的表放在同一个分片上（纯水平切分）。
• 分布式事务问题。
• 分库后跨节点合并排序分页问题。这种情况，需要将各个分片上执行的结果及进行累加。这个累加可以在应用层面，当然，也可以放在中间件层面上。
  多数据源管理问题。

切分的一些原则
由于数据切分后数据 Join 的难度在此也分享一下数据切分的经验：
第一原则：能不切分尽量不要切分。
第二原则：如果要切分一定要选择合适的切分规则，提前规划好。
第三原则：数据切分尽量通过数据冗余或表分组（Table Group）来降低跨库 Join 的可能。
第四原则：由于数据库中间件对数据 Join 实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表 Join。

数据库的切分引申的 数据源管理思考
主要有两种思路：
A. 客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据
库，在模块内完成数据的整合；
B. 通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；

参考：
https://blog.csdn.net/mingover/article/details/71108852?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3