開源項目：TSharding-client
原因
1、單臺數據庫的數據量、數據處理能力是有限的。
2、分庫分表用於應對互聯網常見的兩大場景：大數據量、高併發。
3、分庫分表後，採用最終一致性的柔性事務居多，eventual consistency。
策略
1、垂直切分，將表按照功能模塊、關係密切程度劃分部署到不同庫表上。
2、水平切分，將表中的數據按照某種規則切分成結構相同的多個表和不同庫上，通常是分片算法。
3、如果表太多而造成海量數據，並且業務邏輯劃分清晰、低耦合，則垂直切分，簡單明瞭，容易實施。
4、如果表並不多，但單表數據量很大或數據熱度很高，則水平切分，做數據物理分割，考慮分割粒度、數據平均、負載平均、後期管理。
5、分片策略：按時間、名稱、hash。
問題
1、分庫分表後，數據庫事務管理困難。如果依賴數據庫本身的分佈式事務管理功能去執行事務，將付出高昂的代價。如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
2、表關聯join操作受到限制，無法join不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢就能夠完成的業務，可能需要多次查詢才能完成。
3、額外的數據管理負擔，最明顯的就是數據的定位問題和數據的增刪改查的重複執行的問題，這些都可以通過程序解決，但必然引起額外的邏輯運算。例如對於一個記錄用戶成績的數據表usertable，業務要求查詢出成績最好的100位，在進行分表之前，只需要一個order by就可以搞定，但分表後，將需要n個order by，分別查出每個分表的前100位，然後對這些數據進行合併計算，才能得出結果。
規格
1、基於sharding支持分庫分表
2、支持數據源路由
3、支持分佈式事務
4、支持結果集合並
5、支持讀寫分離
6、支持ORM框架
7、其他：分片規則配置、Sql解析、Sql改寫、Sql路由、Sql執行、結果歸併。
8、分片框架很像mysql 的fabric
技術
做數據與shard對應表，每次請求先從這張表中找shard id，再從shard中查詢數據。
動態hash
多hash表： 採用多個hash表的方式擴展原hash表。
可擴展的動態散列：引入一個僅存儲桶指針的目錄數組，用翻倍的目錄項數來取代翻倍的桶的數目，且每次只分裂有溢出的桶，從而減小翻倍的代價。
線性散列：它能隨數據的插入和刪除，適當的對hash桶數進行調整，與可擴展散列相比，線性散列不需要存放數據桶指針的專門目錄項，且能更自然的處理數據桶已滿的情況，允許更靈活的選擇桶分裂的時機，因此實現起來相比前兩種方法要複雜。