隨著大型互聯網應用的發展，海量數據的存儲和訪問成為系統設計的瓶頸，分布式處理成為不二選擇。數據庫拆分，特別是水平分庫是個高難度的活，涉及一系列技術決策。
　　本人有幸負責1號店訂單水平分庫的方案設計及實施落地，這里結合項目實踐，對水平分庫做一個系統地剖析，希望為大家水平分庫（包括去IOE）改造提供思路，主要內容包括：
　　水平分庫說明分庫維度– 根據哪個字段分庫分庫策略– 記錄如何分配到不同庫分庫數量– 初始庫數量及庫數量如何增長 路由透明– 如何實現庫路由，支持應用透明分頁處理– 跨多個庫的分頁case如何處理Lookup映射—非分庫字段映射到分庫字段，實現單庫訪問整體架構– 分庫的整體技術架構 上線步驟– 分庫改造實施上線項目總結
　　水平分庫說明
　　數據庫拆分有兩種：
　　1）垂直分庫
　　數據庫里的表太多，拿出部分到新的庫里，一般是根據業務劃分表，關系密切的表放同一數據庫，應用修改數據庫連接即可，比較簡單。
　　2）水平分庫
　　某張表太大，單個數據庫存儲不下或訪問性能有壓力，把一張表拆成多張，每張表存放部分記錄，保存在不同的數據庫里，水平分庫需要對系統做大的改造。
　　
　　1號店核心的訂單表存儲在Oracle數據庫，記錄有上億條，字段有上百個，訪問的模式也是復雜多樣，隨著業務快速增長，無論存儲空間或訪問性能都面臨巨大挑戰，特別在大促時，訂單庫已成為系統瓶頸。
　　通常有兩種解決辦法：
　　1）Scale up，升級Oracle數據庫所在的物理機，提升內存/存儲/IO性能，但這種升級費用昂貴，并且只能滿足短期需要。
　　2）Scale out，把訂單庫拆分為多個庫，分散到多臺機器進行存儲和訪問，這種做法支持水平擴展，可以滿足長遠需要。
　　1號店采取后一種做法，它的訂單庫主要包括訂單主表/訂單明細表（記錄商品明細）/訂單擴展表，水平分庫即把這3張表的記錄分到多個數據庫中，訂單水平分庫效果如下圖所示：
　　
　　原來一個Oracle庫被多個MySQL庫取代，支持1主多備和讀寫分離，主備之間通過MySQL自帶的數據同步機制（SLA《1秒），所有應用通過訂單服務訪問訂單數據。
　　分庫維度
　　水平分庫首先要考慮根據哪個字段作為分庫維度，選擇標準是盡量避免應用代碼和SQL性能受影響，這就要求當前SQL在分庫后，訪問盡量落在單個庫里，否則單庫訪問變成多庫掃描，讀寫性能和應用邏輯都會受較大影響，。