关于分库分表思考

1.为什么要分库分表

1.提升性能

1.单表数据量过大，查询索引树高度过高，查询效率低下，加索引等提升效率有限，分表可以减小查询索引树，提高查询效率
2.单库查询更新多，qps负载过高，分库可以减少单库压力
3.单表字段过多，部分非关联字段更新不需要相互阻塞，分表减少竞争锁压力
4.单表存储是有限的

2.提高可用性

1.读写分离，减少写库的压力
2.单库故障，是百分百故障，若分5个库，故障单库故障率20%，其他库可用
3.单表数据量大，备份和恢复时间比较长

2.分库分表的方式

1.垂直切分

垂直切分就是将一张表的部分字段拆出来单独建表，此总方式，多用于业务隔离，独立处理
比如account表存放账号相关信息，user表存放账号的身份信息
垂直切分解决的是锁竞争问题，且使业务独立清晰

2.水平切分

水平切分是将一张表的结构复制，数据根据一定的规则散落在相对应的表里
比如order_1表和order_2表，结构相同，按id奇数存order_1表偶数存order_2表
常用分库分表策略：
1.取余\取模 ： 优点 均匀存放数据，缺点 扩容非常麻烦
2.按照范围分 ： 比较好扩容， 数据分布不够均匀
3.按照时间分 ： 比较容易将热点数据区分出来
4.按照枚举值分 ： 例如按地区分
5.按照目标字段前缀指定进行分区：自定义业务规则分
水平切分主要解决查询效率问题，和单表存储问题

3.分库分表带来的问题

1.分库分表后查询方式需要分析能否使用规则列，不能使用规则列就会需要查询所有表
2.分库后会有分布式事务问题
3.关联表查询join问题，分库之后关联表也需要考虑是否跟着分库
4.主键重复问题，需要考虑统一生成主键，避免重复带来的业务影响
5.分页问题，当多表分页无法跨库join，翻页影响需要处理备用方案
6.聚合函数，分组 ，sum avg等函数使用都需要再次考虑能否使用，使用是否合适

4.何时分库分表

对于垂直分表来说，在业务开始之初，大多数情况都能预计到后续业务变化不同，业务隔离，减少后续分表费时费力，垂直分片往往需要对架构和设计进行调整，所以越早越好
但是对于水平分表，在阿里巴巴公布的开发手册中，建议MySQL单表记录如果达到500W这个级别，或者单表容量达到2GB，一般就建议进行分库分表。如果在业务设计之初就能预估到短期内数据会猛增，在系统设计之初就分表，后续减少维护麻烦，但此时分库也有问题，业务走向不明确的话，无法评估分表规则，不好的规则可能导致分布不规则，单表压力大，单表无数据。
如果开始由于时间紧凑，或者对系统业务预估不足，没有拆表，后续就应当先考虑索引、缓存、读写分离等优化不在对性能有质的提升时在考虑分库分表。此时分库分表就会带来诸多问题：
1.旧版数据迁移
2.需要评估旧代码（sql）能否兼容，不兼容，需要修改
3.试错成本大，当分库分表的不彻底时，将不可控制

5.分库分表中间件

1.shardingsphere 官网地址：https://shardingsphere.apache.org/document/current/cn/overview/，应用比较广泛的两种方案
1）ShardingSphere-JDBC

此方案时增强版jdbc，在客户端入侵处理sql，特点是：
适用于任何基于 JDBC 的 ORM 框架
支持任何第三方的数据库连接池
支持任意实现 JDBC 规范的数据库
2）.ShardingSphere-Proxy

此方案时数据对数据库代理，客户不用处理分片逻辑，将代理当成独立数据库，优点是 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用；
适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。
2.mycat 官网地址： http://www.mycat.org.cn/ ，github：https://github.com/MyCATApache/Mycat-Server
特点还在学习中
3.DBLE 官网地址：https://opensource.actionsky.com/ 特点还在学习中

6.怎么落地

1.分析业务适合什么的中间件，根据中间件特性选型
2.分析查询语句，确定分片规则
3.备用方案，减少试错成本