Sharding | 数据分片策略：分片键和分片算法的选择

摘要：规划分片策略的过程需要考虑较多的问题，本文简单地概括了分片键应具有的特性，以及常见分片算法的特点。

Sharding 作为海量存储高并发沙场中的制胜利器，制定合理的 Sharding 策略会为系统提供强有力的性能保障，选择合适的分片键和分片算法，是分片策略规划中的重要工作。由于业务特点各不相同，分片键和分片算法的选择没有绝对统一的模板。

本文聚焦于分片键和分片算法话题，因此这里不再展开 Sharding 的概念，对于多数业务场景，分库分表的规划方案回顾如下：

• 数据量大，选分表；
• 并发高，选分库；
• 海量存储+高并发，分库+分表。

何时去分表？

当潜意识里有要做分表的想法时，您当前或许遇到了单表过大、数据检索慢以及业务抱怨等问题，需要对系统进行优化。业内关于“单表过千万”、“数百 G”则需要分表的说法，其实不完全准确。以 MySQL 为例，生产中单表数千万记录并不是个例，它没有那么脆弱，合理的架构设计也可有效提升数据检索压力，如优化索引、历史数据归档、引入缓存方案以及启用读写分离策略等。

当数据量激增，以上优化方案均不奏效时，那么是时候请“分表”出场了，单片容量无固定限制，结合测试结果，满足效率和预留空间需求即可。分表的时机不取决于经验之谈，而是取决于业务效率。

何时去分库？

分表概念外，还有一个概念是分库，也总是有朋友会纠结，我到底是否需要分库。分库的底层逻辑是，通过多台服务器来承接更多的业务流量，给系统提供更多的连接支持