北京
你正在白板上畫著數據庫架構，信心滿滿地拋出“然后我們給數據庫做分片（Sharding）。”面試官笑了，追問一句：“為什么？為什么不能就用數據庫分區（Partitioning）？”你愣住了。
這就是缺乏生產級心智模型的下場。教科書定義說“分區是本地操作，分片是分布式操作”，但當系統真正出問題時，這些干凈的定義救不了你。今天我們拋開小抄，看看兩者真正的運維差異、隱藏瓶頸，以及怎么選。
在寫任何DDL之前，先記住一條黃金法則：所有分片都是分區，但不是所有分區都是分片。分區是把數據切成小塊，目標是為了可管理性或性能，比如讓查詢跑得更快。分區不一定意味著分布式系統。分片是一種特殊類型的分區，這些分區分布在不同的機器上，這才是真正的水平擴展。分片的核心目標就兩個——更高的吞吐量、更大的存儲容量。
我們先看第一個場景。假設你搭了個電商平臺，訂單表膨脹到了5億行，延遲圖慘不忍睹，查最近訂單的請求慢得爬一樣。最佳做法是按日期或月份分區。查詢變快，舊分區可以歸檔，維護簡單，還沒有額外的機器成本。工程收益是：分區剪裁，用戶查最近訂單時，查詢計劃器瞬間忽略掉95%的表，只在特定月份的分區文件里搜；還有零成本數據留存，數據變舊后，不用跑一次鎖死CPU的大規模Delete，直接刪除或歸檔整個歷史分區文件就行。看到沒？分區解決的是查詢效率，不是機器容量。
現在看第二個場景。你的平臺爆火，有了5000萬活躍用戶，主數據庫機器寫吞吐撐不住了。CPU打滿，磁盤I/O飽和，連接池耗盡。這時候光靠分區不夠了，瓶頸不再是查詢優化，而是單機資源。一旦CPU、內存、存儲或者寫吞吐成為數據庫機器的瓶頸，你就得考慮分片。你可以把用戶ID 1到1000萬映射到分片A，1000萬到2000萬映射到分片B，以此類推。這樣寫請求就分散到不同的分片上，寫吞吐自然就上去了。
記住，分區能救字段漫無目的的查詢，分片才能解資源到頭了的困局。下次面試再被追問，別復述定義，把這兩個場景甩出來，你看到的就不是問題，而是心照不宣的微笑。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
