MySql分库分表

😀 这里写文章的前言：
分库分表

📝 分库分表要解决的问题

1. 解决B+树设计上本身的瓶颈问题(数据过多, 以及内存不够放索引,需要发生IO之类的问题)
2. 解决技术问题之后,要考虑业务的拆分情况,尽可能的减少业务代码的改动逻辑
3. 分库分表的本质就是把B+树的设计瓶颈重新拆散,变成无瓶颈

📔 垂直切分

通过将不同业务的数据，放到不同的数据库中，实现不同业务之间数据库层面的隔离

📔 水平切分

可以按照某种规则将某些字段分散到多个库中，每个表中只包含一部分数据 ,字段是一样的(比如日期字段，用户id字段，区域字字段等，比较理想的切分字段)

📔 如何实施

1. 先评估是否需要拆分

能不能有其他更好的优化方案，分库分表的开发周期比较长，一般只作为兜底方案去执行

2. 定制拆分的详细方案

1. 选择合适的分表策略
2. 再通知可能要更改的下游
3. 尽量做好设计，避免分库分表带来的常见问题

3. 目的评估

1. 评估：拆成几个表，几个库
2. 目标：读写能力提升多少，负载降低多少，容量支持未来N年的发展

举个例子：

当前30亿数据，如何拆分

解答：

找一个合理的拆分情况，比如按区域，按门店去拆分，不影响原来的业务，并且颗粒度细致到足够未来N年的发展就可以了

4. 拆分完成后防止问题兜底方案

**作用：**保证切换数据源之后，正常的增量数据也同步写入一份到旧数据源，这样能保证新数据发生不可短时间解决的问题的时候，避免回滚可以通过开关配置切换到旧数据源上正常执行业务

方案：

1. 同步双写：同步写新、旧数据源（代码层面上直接改）
2. 异步双写：通过监听binlog的方式去写旧数据源
3. 中间件同步工具：通过中间件工具去实施同步数据

注意点：做好补偿机制， 因为可能写其中一个库失败，需要做好最终一致性问题

5.存量数据的迁移问题

作用：迁移旧数据源的数据同步到新的数据源上，保证原有业务的正常CRUD

方案：

1. 自己写job开发，查询旧数据源，写入新库

2.用中间件去同步

3.交给DBA去同步

注意点：一定要校验数据的准确性，因为这是分库分表后的最后一步，一定要再三确认数据的一致性校验问题，并且要有相关的job做好补偿方案

分库分表后存在的问题

分布式id问题

1. 雪花算法，
2. 全局的自增id，
3. 美团分布式id方案

跨表查询问题

1. 从设计上解决跨表查询的情况，设计上基本能解决95%以上的问题，比如冗余字段，拆分的时候按业务隔离性去拆分
2. 分开查询，通过java代码去组合数据
3. 同一个线程需要跨库的，可以通过JDBC的方式去查询
4. 用ES等查询工具查询出主要信息，再组装数据

分布式事务问题

1. 做好补偿方案
2. 最大努力通知（使用MQ）
3. 人工兜底补偿 - 保底

📔 切分策略

范围切片

• 优点： 天然水平扩展;单表大小可控
• 缺点：存在明显的写偏移

中间映射表

• 优点： 灵活
• 缺点： 引入额外的单点，增加了流程的复杂度

hash切分

• 优点： 数据分片比较均匀，不容易出现热点和访问并发的瓶颈
• 缺点： 后续扩容需要迁移数据，存在跨节点查询等问题

🤗 总结归纳

📎 参考文章

💡 有关文章的问题，欢迎您在底部评论区留言，一起交流~