随之业务数据的激增， 传统单库单表管理数据的方式已跟不上数据管理的需要。解决过程中， 针对大量数据做分库分表，成了一个常用的方案。分库分表过程中，到底选哪一个业务字段来作Sharding Key，成了一个影响深远的问题，需要谨慎考虑。应该说，围绕这个问题， 还不存在一刀切非黑即白的方案， 不过有一些共同的原则可以帮咱做出正确的千把
找出Sharding Key
分库分表设计中，最困难的一个任务是视别出一个Sharding Key来。分库分表整体方案中， 有很多策略受此影响。Sharding Key一旦选定后，也不能再方便快速地调整。这样， 在最开始时， 选一个正确的Sharding Key，成了至关重要的问题。
最好是选最小粒度的业务实体作Sharding Key
以一家管理公司资产的SaaS提供商为例，被管理的公司中一般都会有多个子公司，每一个子公司都有大量的资产。每一份资产可以产生大量的数据， 也是众多数据管理事务的枢纽点。针对此场景，如何选Sharding Key， 有人可能会选公司，有人选子公司，也有人选资产。据最佳实践来看， 推荐选资产来做为Sharding Key。
业务中是不是所有的DML操作都会遍历所有的分片？
理想的数据建模中， 我们是要避免跨分片的数据操作。不过，业务场景中， 这种跨分片的操作不可避免，我们也只能退而求其次地把这样的跨片查询降到最低。围绕这个诉求，数据访问层的功能会复杂很多， 数据库的可用性和可靠性会受影响，如果一个分片宕机后，业务风险很大。
可以考虑分片上的逻辑集合（logical grouping）
分片上的逻辑集合是一个分片集（shard set）。分片集里的实体和数据库对象可以单个分片之间访问。例如，一个逻辑数据模型中可以有多个相互独立的功能区， 如库存、销售和客户， 每一个都可以是分片集。每一个分片集里有一个共用的分片Key，如库存中使用ProductId， 销售记录和用户分片中使用CustomerID。针对Sales域，一个不太常用的方案是使用SalesOrderID作为分片Key。背后的考虑是，跨分片的查询是否支持。
另一个经常会碰到的问题是，跨分片集的逻辑关系怎么管理。如果必要的话，应用层必须使用跨区（cross-area）的事务来补偿了。本例中，Sales分片集里，有一个针对Products分片集的logical relationship，即对ProductId的引用。针对此问题， 一个可选的方案是，在Sales分片集里， 将Products表定义为参考表（reference table）。不过， 这个方案并不总是有效，可能在Orders分片或配送分片中也都需要有Products引
考虑Shard Key的数据类型
Shard Key的数据类型影响到数据的维护、问题排查和资源使用情况。最有效的数据类型最好有固定的存储大小，也要很适合CPU处理。这些因素组合起来后， 可选的类型有integers (smallint, int, and bigint)，char (4 -> 8), 或binary (4 -> 8)。其中，bigint (Int64)是最好的选择。
希望上面汇总的一些考虑点， 可以帮助到你。
---------
往期推荐
~~~~~~~~~~~~~
长按二维码，关注公众号
一起推进电商业务信息化
