原则

分库分表有一个前提：能不拆就不拆，能少拆就少拆。因为拆分会带来开发和后期维护的成本。那为什么仍然需要分库分表呢？第一，某些系统还是需要依赖MySQL来保证金融级的事务。第二，MySQL本质是单机数据库，支持不了太大的数据量和高并发。所以只能是，数据量和并发大到没其他办法了，我们才分库分表

• 分表： 解决查询慢，让每次查询的数据总量减少。
• 分库： 解决高并发。

如何选择Sharding Key?

主要的考虑因素就是：业务是怎么查的。例如订单系统，如果根据订单ID（主键）进行分片，查订单ID的时候就根据订单ID和分片算法找到是哪个分片就在分片上查就行了。但是如果是用户订单界面，查的是用户ID呢？这个问题可以这样解决，根据用户ID分片，然后规定订单ID的10-14位为用户ID的后四位，，查订单ID的时候通过10-14位找到分片位置。

但如果有各种各样的查询呢？例如商家查询自己店铺的订单，各种订单数据报表统计等等。一般做法是把订单数据同步到其他存储系统里面去，去其他存储系统解决。例如我们再构建一个以店铺ID作为sharding key的只读订单库，给商家查询。或者把订单同步到HDFS(Hadoop分布式文件系统)中，用大数据技术生成报表

如何选择分片算法

• 范围分片，例如根据订单的时间来分片。
  ??这种方式对查询比较友好，我们可以规定所有查询都必须带上时间，那么就可以支持各种各样的查询。
  ??容易出现热点数据。如大部分查询都是针对最近三个月的查询，那么其他历史时间的分片根本用不上。不太适合并发量很大的情况。

• 哈希分片
  通过哈希算法。要保证sharding key均匀分布。

• 查表
  自定义规定一个分片映射表，查数据前先查映射表。
  ??灵活性高，分片可以随时改变，可以人为让数据均匀分布
  ??性能较差，如果分片映射表本身数据太多，那么这个表将成为热点和性能瓶颈（但可以通过缓存来加速）。