解决海量数据的问题，必须要用到分布式的存储集群，因为 MySQL 本质上是一个单机数据库，所以很多场景下不是太适合存 TB 级别以上的数据。

但是，绝大部分的电商大厂，它的在线交易这部分的业务，比如说，订单、支付相关的系统，还是舍弃不了 MySQL，原因是，**只有 MySQL 这类关系型数据库，才能提供金融级的事务保证。**我们之前也讲过分布式事务，那些新的分布式数据库提供的所谓的分布式事务， 多少都有点儿残血，目前还达不到这些交易类系统对数据一致性的要求。

既然MySQL支持不了这么大数据量、这么大并发。但是还需要用它，怎么解决这个问题呢？那就必须要采用**分片。**比如1TB的数据，拆100个库，每个库只有10GB的数据了。

如何规划分库分表呢？

1. 第一，数据量太大，增删改查慢的问题。解决查询慢的问题，只需要减少每次查询的数据总量就可以了。也就是说，分表就可以解决问题。
2. 第二，为了应对高并发的问题，一个数据库实例支撑不住，就把并发的请求分散到多个实例中去，所以解决高并发，需要采用分库。

简单来说，数据量大，就分表；并发高，就分库。

另外，不建议考虑二次扩容的问题，因此到时候业务早就变了。

如果选择Sharding Key

选择合适 Sharding Key 和分片算法非常重要，直接影响了分库分表的效果。我们首先来说 如何选择 Sharding Key 的问题。

订单表如下所示：

选择这个 Sharding Key 最重要的参考因素是，我们的业务是如何访问数据的。

把订单 ID 作为 Sharding Key 来拆分订单表，那拆分之后，如果我们按照订单 ID来查订单，就需要先根据订单 ID 和分片算法计算出，我要查的这个订单它在哪个分片上，也就是哪个库哪张表中，然后再去那个分片执行查询就可以了。