這個方法會對 shard 鍵使用數學公式 (雜湊函式) 來指派資料。舉例來說，系統可能會計算使用者 ID (mod 4)，將使用者指派給 4 部伺服器中的 1 部。

雖然雜湊函式有助於一致地分配資料，但只有在 shard 鍵具高基數和低頻率偏差時，才能確保均勻分配。如果選擇的 shard 鍵值很常見，例如「Last Name」中「Smith」出現的次數比「Pyne」多 1,000 次，雜湊函式就會將所有「Smith」記錄傳送至同一個 shard。即使使用數學公式，仍會建立「熱 shard」。

此外，由於公式會變更，這通常需要「重新分割」或在新的伺服器叢集間移動資料，因此採用這種方法時，新增伺服器也很困難。

系統會根據值範圍，指派資料。舉例來說，您可以將使用者 ID 1 到 1,000 放在伺服器 A，並將 1,001 到 2,000 放在伺服器 B。這項功能非常直覺，適合用於需要讀取一系列資料的查詢 (範圍查詢)。但這種做法的缺點是會產生「熱點」，也就是說，如果所有新使用者都指派給伺服器 B，該伺服器就會負責所有工作，而伺服器 A 則閒置。

這項策略會使用對照表 (目錄) 追蹤哪個 shard 包含哪些資料。這種做法最彈性，因為您可以在 shard 之間移動資料，不必變更公式。不過，這個對照表會成為瓶頸，因為每個查詢都必須先檢查目錄，所以會增加延遲。如果目錄發生故障，就會無法存取整個資料庫。

地理 sharding 會根據使用者的實際位置，將資料指派給特定伺服器。舉例來說，法國使用者的資料會儲存在歐盟地區的伺服器，而美國使用者的資料則會儲存在北美地區的伺服器。這可為使用者大幅縮短延遲時間 (速度)，並協助公司遵守 GDPR 等資料落地法規。

有時稱為功能分區，這種做法是依據特徵而非資料列來分割資料。舉例來說，您可以將所有「使用者個人資料」資料表放在伺服器 A，並將所有「相片上傳」資料表放在伺服器 B。雖然這種做法能以邏輯方式整理資料，但功能上與微服務資料架構類似，如果特定功能 (例如相簿) 的資料量過大，單一伺服器就無法負荷，並不能解決問題。

sharding 是一種水平分區，會將資料分配到完全不同的伺服器。由於不同伺服器可以同時處理寫入作業，因此能解決硬體容量限制 (儲存空間) 和寫入處理量瓶頸。

• 手動 sharding：在手動 sharding 環境中，開發人員或資料庫管理員必須負責定義 shard 鍵、為每個 shard 建立基礎架構，以及編寫查詢轉送邏輯。讓您精細控管資料的存放位置。不過，這需要大量維護作業。如果某個 shard 變得過大，您必須手動「重新分割」資料，也就是將數百萬列資料移至新伺服器，同時盡可能縮短應用程式停機時間。
• 自動 sharding：在 Bigtable 等 NoSQL 資料庫，或 Spanner 等分散式 SQL 資料庫中，通常會提供自動 sharding 功能，能自動處理資料和流量分配作業。系統會監控資料大小和各伺服器的負載。如果特定 shard 成為「熱點」或過於龐大，資料庫引擎會自動分割 shard，並將資料移至較不擁塞的伺服器。這能減輕團隊的作業負擔，並確保應用程式擴充時維持一致的效能。

分區是將大型資料表分割成較小、更易於管理的部分 (例如按月分割記錄資料表)，但這些部分仍保留在同一個伺服器執行個體。這樣一來，您就能輕鬆封存或刪除舊資料，而不影響資料表中的其他內容，解決儲存空間問題。但無法解決伺服器問題。由於所有分區仍位於同一部機器，因此會繼續共用相同的 CPU 和 RAM，這表示如果伺服器達到效能上限，即使是分區也沒有幫助。

複製是指將整個資料庫複製到多部伺服器。如果想確保讀取作業的可用性，這會是不錯的選擇，因為當一個伺服器故障時，另一個伺服器可以接管。不過，由於寫入的每筆資料都必須複製到每個副本，因此寫入速度會受限於單一機器的容量，對於調度寫入資源沒有幫助。

同樣重要的是，大多數複製模型一次只允許一個「寫入者」(主要節點)。如果嘗試讓多部伺服器同時接受寫入作業，可能會發生寫入衝突，也就是兩部伺服器嘗試以不同資訊更新同一筆記錄。解決這些衝突在技術上相當困難，如果沒有由複雜的分散式系統處理，可能會導致資料遺失或不一致。

Spanner 等分散式資料庫具備 sharding 的優勢，並能免除手動作業。這些系統從一開始就設計成可跨機器叢集運作。這些系統會自動處理資料分布、重新平衡，並以公開透明的方式處理複製作業。其中有些系統有多個寫入者，並會自動處理寫入衝突。這可讓您水平擴充，同時維持傳統關聯式資料庫的一致性。