上述已经讲了一些分库分表的基础概念和一些特点。下面主要讲一下分库分表的一些推荐方案

分库分表以后可能产生的问题

开篇讲过，不建议分库分表，但是数据量达到一定量时，为了依旧能有较好的性能体验，分库分表是个不错的选择，但是分库分表以后可能会产生什问题呢，这个是平时项目开发不得不面对的问题。

• join连接无法使用：对于分库的情况，join无法使用，之前在一个库，但是多个库就无法使用了。 就需要使用业务处理代替sql的连接查询，需要考虑多次查询的事务性容忍度。
• 事务问题：分库以后，spring的事务是基于单个数据库开发的，多个库就需要使用分布式事务进行处理。
  • // todo spring的事务实现原理
  • // todo 分布式事务
• 分布式ID: 分库以后，数据遍布在不同的数据库，数据库的自增主键已经没办法满足生成的主键唯一，常规的UUID也会存在重复的问题，且效率没有有序主键好，所以就需要使用到分布式ID了，之前似乎写过一篇分布式ID的简单实现，可以参考。
• 聚合查询：这个跟join差不多，就是在不同库，导致了无法使用聚合查询，需要使用代码程序代替，增加了代码的复杂性。
• 需要维护新的数据库，新增了项目成本...等等

以上就是常见的一些问题，虽然上面只说了分库的缺点，但是实际业务场景一般分表分库是同时出现的，大多数单独的分表不能解决问题

分库分表推荐的方案

• Apache ShardingSphere 分布式的数据库生态系统
  • 支持数据分片
  • 分布式事务
  • 读写分离
  • 数据迁移
  • 联邦查询
  • 数据加密
  • 影子库
• TiDB分布式关系型数据库

// todo ShardingSphere的一些使用案例

// todo TiDB分布式关系型数据库使用案例