將存放在同一個數據庫中的數據分散存放到多個數據庫上，實現分布存儲，通過路由規則路由訪問特定的數據庫
這樣一來每次訪問面對的就不是單台服務器了，而是N台服務器，這樣就可以降低單台機器的負載壓力。
sqlserver 2005版本之后，可以友好的支持“表分區”。
垂直(縱向)拆分：是指按功能模塊拆分，比如分為訂單庫、商品庫、用戶庫…這種方式多個數據庫之間的表結構不同。
優點：
1. 拆分后業務清晰，拆分規則明確。
2. 系統之間整合或擴展容易。
3. 數據維護簡單。
缺點：
1. 部分業務表無法join，只能通過接口方式解決，提高了系統復雜度。
2. 受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。
3. 事務處理復雜。
水平(橫向)拆分：將同一個表的數據進行分塊保存到不同的數據庫中，這些數據庫中的表結構完全相同。
優點：
1. 不存在單庫大數據，高並發的性能瓶頸。
2. 對應用透明，應用端改造較少。
3. 按照合理拆分規則拆分，join操作基本避免跨庫。
4. 提高了系統的穩定性跟負載能力。
缺點：
1. 拆分規則難以抽象。
2. 分片事務一致性難以解決。
3. 數據多次擴展難度跟維護量極大。
4. 跨庫join性能較差。
拆分的處理難點
（1）兩種方式共同缺點
- 引入分布式事務的問題。
- 跨節點Join 的問題。
- 跨節點合並排序分頁問題。
（2）針對數據源管理，目前主要有兩種思路：
A. 客戶端模式，在每個應用程序模塊中配置管理自己需要的一個（或者多個）數據源，直接訪問各個 數據庫，在模塊內完成數據的整合。
優點：相對簡單，無性能損耗。
缺點：不夠通用，數據庫連接的處理復雜，對業務不夠透明，處理復雜。
B. 通過中間代理層來統一管理所有的數據源，后端數據庫集群對前端應用程序透明；
優點：通用，對應用透明，改造少。
缺點：實現難度大，有二次轉發性能損失。
（3）拆分原則
- 盡量不拆分，架構是進化而來，不是一蹴而就。(SOA)
- 最大可能的找到最合適的切分維度。
- 由於數據庫中間件對數據Join 實現的優劣難以把握，而且實現高性能難度極大，業務讀取 盡量少使用多表Join -盡量通過數據冗余，分組避免數據垮庫多表join。
- 盡量避免分布式事務。
- 單表拆分到數據1000萬以內。
（4）拆分方案
范圍、枚舉、時間、取模、哈希、指定等
（5）案例分析
場景一
建立一個歷史his系統，將公司的一些歷史個人游戲數據保存到這個his系統中，主要是寫入，還有部分查詢，讀寫比約為1:4；由於是所有數據的歷史存取，所以並發要求比較高；
分析：
歷史數據
寫多都少
越近日期查詢越頻繁？
什么業務數據？用戶游戲數據
有沒有大規模分析查詢？
數據量多大？
保留多久？
機器資源有多少？
方案1：按照日期每月一個分片
帶來的問題：1.數據熱點問題（壓力不均勻）
方案2：按照用戶取模， –by Jerome 就這個比較合適了
帶來的問題：后續擴容困難
方案3：按用戶ID范圍分片（1-1000萬=分片1，xxx）
帶來的問題：用戶活躍度無法掌握，可能存在熱點問題
場景二
建立一個商城訂單系統，保存用戶訂單信息。
分析：
電商系統
一號店或京東類？淘寶或天貓？
實時性要求高
存在瞬時壓力
基本不存在大規模分析
數據規模？
機器資源有多少？
維度？商品？用戶？商戶？
方案1：按照用戶取模，
帶來的問題：后續擴容困難
方案2：按用戶ID范圍分片（1-1000萬=分片1，xxx）
帶來的問題：用戶活躍度無法掌握，可能存在熱點問題
方案3：按省份地區或者商戶取模
數據分配不一定均勻
場景三
上海公積金，養老金，社保系統
分析：
社保系統
實時性要求不高
不存在瞬時壓力
大規模分析？
數據規模大
數據重要不可丟失
偏於查詢？
方案1：按照用戶取模，
帶來的問題：后續擴容困難
方案2：按用戶ID范圍分片（1-1000萬=分片1，xxx）
帶來的問題：用戶活躍度無法掌握，可能存在熱點問題
方案3：按省份區縣地區枚舉
數據分配不一定均勻