此方法使用分片键上的数学公式（哈希函数）来分配数据。例如，系统可能会计算用户 ID (mod 4)，以将用户分配到 4 个服务器之一。

虽然哈希函数有助于一致地分布数据，但只有在分片键具有高基数和低频率偏度时，它们才能确保均匀分布。如果您选择一个具有常见值的分片键（例如“姓氏”中“Smith”出现的次数是“Pyne”的 1,000 倍），则哈希函数会将每个“Smith”记录发送到同一分片。尽管使用了数学公式，但仍会创建“热分片”。

使用这种方法也很难添加新服务器，因为公式会发生变化，这通常需要您“重新分片”或将数据移动到新的服务器集群中。

数据是根据值范围分配的。例如，您可以将用户 ID 1-1,000 放在服务器 A 上，将用户 ID 1,001-2,000 放在服务器 B 上。这种方法非常直观，非常适合需要读取一系列数据（范围查询）的查询。缺点是会出现“热点”：如果所有新用户都被分配到服务器 B，那么服务器 B 将承担所有工作，而服务器 A 则处于空闲状态。

此策略使用一个对照表（目录）来跟踪哪个分片包含哪些数据。这种方法最灵活，因为您可以在分片之间移动数据，而无需更改公式。但是，此对照表会成为瓶颈；每个查询都必须先检查目录，从而增加延迟。如果目录发生故障，整个数据库都将无法访问。

地理分片会根据用户的实际位置将数据分配给特定的服务器。例如，法国用户的数据存储在欧盟的服务器上，而美国用户的数据则存储在北美的服务器上。这显著降低了用户延迟（速度），并帮助公司满足 GDPR 等数据驻留法律的要求。

有时称为功能分区，这种方法涉及按特征而不是按行拆分数据。例如，您可以将所有“用户个人资料”表放在服务器 A 上，并将所有“照片上传”表放在服务器 B 上。虽然这种方式可以从逻辑上整理数据，但从功能上来说，它与微服务数据架构类似，如果某个特定功能（如照片）的数据量过大而使单个服务器无法处理，这种方式也无法解决问题。

分片是一种特殊的水平分区类型，其中数据块分布在完全不同的服务器上。这既解决了硬件容量限制（存储）问题，也解决了写入吞吐量瓶颈问题，因为不同的服务器可以同时处理写入操作。

• 手动分片：在手动分片环境中，开发者或数据库管理员负责定义分片键、为每个分片创建基础设施，并编写用于路由查询的逻辑。这样，您就可以精细地控制数据的存储位置。不过，这需要大量的维护工作。如果某个分片变得过大，您必须手动对数据进行“重新分片”，这需要将数百万行数据移动到新服务器，同时尽量减少应用停机时间。
• 自动分片：自动分片通常用于 Bigtable 等 NoSQL 数据库或 Spanner 等分布式 SQL 数据库，可自动处理数据和流量的分布。系统会监控数据大小和每个服务器上的负载。如果特定分片成为“热点”或变得过大，数据库引擎会自动拆分该分片并将数据移至不太拥塞的服务器。这可以减轻团队的运营负担，并帮助确保应用在扩缩时保持一致的性能。

分区是将大表拆分成更小、更易于管理的部分（例如按月拆分日志表），但这些部分仍保留在同一服务器实例上。这解决了存储问题，因为这样可以更轻松地归档或删除旧数据，而不会影响表的其余部分。但它无法解决服务器问题。由于所有分区仍驻留在单台机器上，因此它们继续共享相同的 CPU 和 RAM，这意味着如果服务器达到性能极限，分区也无济于事。

复制是将整个数据库复制到多个服务器的过程。这对于读取可用性来说是一个不错的选择；如果一个服务器发生故障，另一个服务器可以接管。不过，它无法帮助进行写入扩缩，因为写入的每条数据都必须复制到每个副本，从而将写入速度限制在单台机器的容量范围内。

同样重要的是，大多数复制模型一次只允许一个“写入者”（主节点）。如果您尝试允许多个服务器同时接受写入，则可能会发生写入冲突，即两个服务器尝试使用不同的信息更新同一条记录。从技术上讲，解决这些冲突非常困难，如果不是由复杂的分布式系统处理，可能会导致数据丢失或不一致。

Spanner 等分布式数据库提供了分片优势，而无需手动操作。这些系统从一开始就设计为跨机器集群运行。它们会自动透明地处理数据分发、重新平衡和复制。其中一些系统有多个写入者，并自动处理写入冲突。这样，您就可以在保持传统关系型数据库一致性的同时进行横向扩缩。