# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：PlanetScale (@PlanetScale) · 平台：X (Twitter) · 日期：2026-04-16

> 原始來源：https://x.com/PlanetScale/status/2044471520484086003

## 中文摘要

分片是擴展資料庫的最佳方式。

PlanetScale於2025年1月9日發布互動式文章，詳細解釋資料庫分片（sharding）的運作原理與設計考量，強調這是處理PB等級資料與每秒數百萬查詢的首選方案，Uber、Shopify、Slack與Cash App皆以此搭配Vitess與MySQL擴展龐大資料庫。

**分片基礎架構**  
小型網頁應用通常由單一單體資料庫伺服器處理所有持久化資料與查詢，每秒僅需數百至數千筆即可應付。但熱門應用常有數十萬並發使用者，需儲存PB等級資料並在尖峰時處理每秒數百萬查詢，此時單一伺服器難以負荷，必須將資料分散至多台獨立資料庫伺服器，每台僅持有一部分總資料。  
應用伺服器需知曉所有分片位置、資料列歸屬，並維持與各分片的連線；少數分片時尚可行，但數百分片時邏輯複雜，嵌入應用程式碼易造成維護噩夢。  
較佳方案是引入代理伺服器（proxy），應用伺服器僅向其發送查詢，由代理負責路由至正確分片，簡化應用端設計。

**分片策略選擇**  
分片策略決定資料列分配至哪個分片，通常選定分片鍵（shard key，一或多個欄位）作為規則基礎，直接影響資料分佈均勻度與查詢效能。  
- **範圍分片（Range sharding）**：代理依預定義值範圍決定資料列歸屬。  
- **雜湊分片（Hash sharding）**：選定分片鍵，對其值產生加密雜湊，每個分片負責特定雜湊範圍，由代理控制分配，是最受歡迎策略。  
- **其他策略**：Vitess等軟體支援查詢分片（lookup sharding）或自訂分片函數，涵蓋多數情境。

**跨分片查詢風險**  
理想設計是單一查詢僅需單一分片處理；跨分片查詢需多台分片參與，帶來過度網路與CPU負荷，嚴重損害系統效能，設計時應盡力避免。

**分片鍵更新挑戰**  
分片鍵欄位值若變更，資料列可能需移轉至其他分片以維持策略完整性，因此選鍵時須考量更新頻率，避免頻繁移動造成效能瓶頸。

**代理層延遲與緩解**  
引入代理增加一跳網路延遲，為明顯缺點；但若代理與分片置於同一資料中心，延遲可壓至1ms以下，影響微乎其微。

**資料持久性與備份優勢**  
無論GB或PB資料，均建議運行複本（replica），由其從主資料庫伺服器複製所有資料，提升耐久性。  
分片設計大幅加速備份：大型資料庫備份時間易失控，但多分片可並行捕捉各自備份，總時間大幅縮短。

**設計總結與工具應用**  
分片是擴展資料庫的絕佳方案，但需精準選擇分片策略、分片鍵並優化查詢，方能確保高效能。本文透過互動式資料庫叢集圖表，讓讀者動手操作範例，加深理解；這些基礎概念有助建構優質分片系統，如運用Vitess與「PlanetScale」。文章忠實呈現分片優缺點，無美化其複雜性，適合大型組織借鏡。

## 標籤

教學資源, 產業趨勢, PlanetScale, Vitess, MySQL