數據庫切片模式關注的實現水平伸縮。切分是從單個數據庫到平分數據訪問兩個或更多數據庫切片。每個切片有和原始數據庫相同的Schema。大多數據分布在每個切片每一行。從切片合並起來的數據和原始數據庫一樣。切片也被近似等同於水平分區(Horizontal Partitioning)，網上很多地方也用水平分區來指代切片，二者之間實際上還是有區別的。的確，切片 的思想是從分區的思想而來，但數據庫分區基本上是數據對象級別的處理，比如表和索引的分區，每個子數據集上能夠有不同的物理存儲屬性，還是單個數據庫范圍內的操作，而切片是能夠跨數據庫，甚至跨越物理機器的。
上下文(Context)
數據庫切片有效應對下面的挑戰：
- 應用數據庫查詢超過單個數據庫結點的查詢能力.
- 應用數據庫更新超過單個數據庫事務處理能力，導致不可接受相應時間或超時。
- 應用數據庫網絡帶寬超過單個數據庫結點的帶寬頁導致不可接受相應時間或超時。
- 應用數據庫存儲需求已超過單個數據庫結點容量。
機制
傳統(非共享)數據庫部署在單個服務器結點上。任何數據庫運行在單個結點受限於當前結點容量。爭奪的資源如CPU，內存，磁盤速度，數據尺寸，和網絡帶寬能損害數據庫能力來處量相關的數據庫活動。過分的爭奪還可能使數據庫承受不了。當單個結點不再夠用時有很多潛在的方法為了實現一個應用數據庫伸縮。一些例子包括：分布式查詢加載到從結點，按數據類型拆分到多個數據庫與垂直伸縮的數據庫服務器。處理查詢加載(非寫/更新),從結點是從主數據復制；從結點是只讀與典型事務一致。另一個選項是按數據類型拆分到多個數據庫，如存貨清單數據在一個數據庫中，雇員數據在另一個數據庫中。每個結點包含數據子集叫做切片。總體地，所有切片中數據呈現一個完整邏輯數據庫。在數據庫服務繼承切片時，切片集合出現在單個數據庫連接字符串中。這個抽象很好簡化了應用程序編程模型。 
如上圖所示，數據行分布到切片，維護着相同的結構，上面一個切片存儲id=1,2，另一個存儲id=3,4,5的記錄。
切分和策略
像很多其他技術一樣，進行切分時也需要作出部分妥協。因為切片不是一項本地數據庫技術 — 也就是說，必須在應用程序中實現 —在開始切片之前需要制定出您的切分策略。進行切分時主鍵和跨切分查詢都扮演重要角色，主要通過定義您不可以做什么實現。
主鍵
切片利用多個數據庫，其中所有數據庫都獨立起作用，不干涉其他切片。因此，如果您依賴於數據庫序列（如自動主鍵生成），很有可能在一個數據庫集中將出現同一個主鍵。可以跨分布式數據庫協調序列，但是這樣會增加系統的復雜程度。避免相同主鍵最安全的方法就是讓應用程序（應用程序將管理切分系統）生成主鍵。
跨切片查詢
大部分切分實現不支持跨切片查詢，這就意味着，如果您想利用不同切分的兩個數據集，就必須處理額外的長度。（有趣的是，Amazon 的 SimpleDB 也禁止跨域查詢）例如，如果將美國客戶信息存儲在切片1中，還需要將所有相關數據存儲在此。如果您嘗試將那些數據存儲在切片2中，情況就會變得復雜，系統性能也可能受影響。這種情況還與之前提到的一點有關 — 如果您因為某種原因需要進行跨切分連接，最好采用一種可以消除重復的方式管理鍵！
很明顯，在建立數據庫前必須全面考慮切分策略。一旦選擇了一個特定的方向之后，您差不多就被它綁定了 — 進行切分后很難隨便移動數據了。
一個策略示例
因為切分將您綁定在一個線型數據模型中（也就是說，您無法輕松連接不同切分中的數據），您必須對如何在每個切分中對數據進行邏輯組織有一個清晰的概念。這可以通過聚焦域中的主要節點實現。如在一個電子商務系統中，主要節點可以是一個訂單或者一個客戶。因此，如果您選擇 “客戶” 作為切分策略的節點，那么與客戶有關的所有數據將移動至各自的切分中，但是您仍然必須選擇將這些數據移動至哪個切分。對於客戶來說，您可以根據所在地（歐洲、亞洲、非洲等）切分，或者您也可以根據其他元素進行切分。這由您決定。但是，您的切分策略應該包含將數據均勻分布至所有切分的方法。切分的總體概念是將大型數據集分割為小型數據集；因此，如果一個特定的電子商務域包含一個大型的歐洲客戶集以及一個相對小的美國客戶集，那么基於客戶所在地的切分可能沒有什么意義。
注意
比如類似交易記錄的歷史表信息，如果一條記錄中既包含賣家信息與買家信息，如果隨着時間推移，買、賣家會分別與其它用戶繼續進行交易，這樣不可避免的兩個買賣家的信息會分布到不同的數據庫切片上，而這時如果針對買賣家查詢，就會跨越更多的切片，開銷就會比較大。
切片並不是數據庫擴展方案的銀彈，也有其不適合的場景，比如處理事務型的應用就會非常復雜。對於跨不同DB的事務，很難保證完整性，得不償失。
在進行切分之前，一定要確定應用程序的規模和增長對其有利。切分的成本（或者說缺點）包括對如何存儲和檢索數據的特定應用程序邏輯進行編碼的成本。進行切分后，您多多少少都被鎖定在您的切分模型中，因為重新切分並非易事。
如果能夠正確實現，切分可以用於解決傳統 RDBMS 規模和速度問題。切分對於綁定於關系基礎架構、無法繼續升級硬件以滿足大量可伸縮數據存儲要求的組織來說是一個非常成本高效的決策。