1. ShardingSphere简单介绍
ShardingSphere是一款目前业内比较流行的分库分表框架，到现在为止有接近十年的开发历程了，其 已经不仅仅只是⽤来做分库分表，⽽是形成了⼀个围绕 分库分表核⼼的技术⽣态。他的核⼼功能已经包括了数据分⽚、分布式事务、读写分离、⾼可 ⽤、数据迁移、联邦查询、数据加密、影⼦库、DistSQL庞⼤的技术体系。
ShardingSphere最为核⼼的产品有两个：⼀个是ShardingJDBC，这是⼀个进⾏客户端分库分
表的框架。另⼀个是ShardingProxy，这是⼀个进⾏服务端分库分表的产品。他们代表了两种不
同的分库分表的实现思路。
2. 为什么需要使用ShardingSphere
在任何一个商城或者收单系统中，单库单表或许在项目早期能够支撑，其就无法满足日益增长的用户和订单需求了，于是必须考虑到分库分表。在业界分库分表的框架有很多，比如Mycat、shardingsphere等等，考虑到Shardingsphere已经被收录进apache，作为顶级项目，且一直在更新维护，此次就选择Shardingsphere作为分库分表的底层框架。
3. 什么时候需要进行分库以及分表
我们知道当数据量过大的时候，我们就需要进行分库分表，那究竟什么时候代表数据量过大了呢？业界⽬前唯⼀⽐较值得参考的详细标准，是阿⾥公开的开发⼿册中提到的，建议预估三年内，单表数据超过500W，或者单表数据⼤⼩超过2G，就需要分库分表
4. 分库分表的难点
可能有些读者会觉得，不就是引入第三方框架，分库分表也蛮简单的呀。对于这类读者，建议多多了解shardingsphere结合实际业务场景的使用，同时思考一个问题，如何在分库分表的同时，保证系统性能不怎么受影响呢？
分库分表不是简单地框架的引入就可以解决的问题，它涉及到一系列的分布式服务问题，包括但不限于分布式订单id、分布式事务、分布式锁、读写分离以及分布式数据库等等业界常见的难点问题。同时如果使用ShardingJdbc进行分库分表的话，并不是所有SQL都能被ShardingSphere支持的，比如一些复杂嵌套查询sql，由于Shardingsphere无法将其按照算法拆分为特定条件，所以就无法被解析，这样在分库分表过程中可能会出现问题。
针对分库分表，我的建议是"能不分就不分"，实在需要分，则在分库分表之前，对系统有很好的设计，同时至少需要考虑以下问题：
主键重复问题
在分库分表环境中，由于表中数据同时存在不同数据库中，某个数据库⽣成的ID就⽆
法保证全局唯⼀。因此需要单独设计全局主键，以避免跨库主键重复问题。
历史数据迁移问题
如果项目已经在生产运行一段时间，产生了各项数据，如何保证引入分库分表后，历史数据依旧可以被正常访问？
数据库扩容带来的数据迁移问题
当数据库集群需要进⾏扩缩容时，集群中的数据也需要随着服务进⾏迁移。如何在不影响
业务稳定性的情况下进⾏数据迁移也是数据库集群化后需要考虑的问题。
分布式事务问题
传统单库单表服务，我们可以使用本地事务进行事务管理，但是在多库多表的环境中，事务应该如何管理？
数据路由问题
插入的数据会被拆分到多个分片中，如何保证数据查询的时候寻找到对应的分片从而使数据不会"丢失"
归并问题
进⾏多个分片查询时，每个分散的数据库中只能查出⼀部分的数据，这时要对整体结果进⾏
归并，⽐如常⻅的limit、order by等操作，如何使数据复合要求？
实际场景中，分库分表带来的挑战不止上述几个问题，不同业务有不同的处理方式，我们很难寻找统一的解决方案去满足所有场景。