Mycat分表分庫原則

分表分庫雖然能解決大表對資料庫系統的壓力，但它並不是萬能的，也有一些不利之處，因此首要問題是，分不分庫，分哪些庫，什麼規則分，分多少分片。 
原則一：能不分就不分，1000萬以內的表，不建議分片，透過合適的索引，讀寫分離等方式，可以很好的解決效能問題。 
原則二：分片數量儘量少，分片儘量均勻分佈在多個DataHost上，因為一個查詢SQL跨分片越多，則總體效能越差，雖然要好於所有資料在一個分片的結果，只在必要的時候進行擴容，增加分片數量。 
原則三：分片規則需要慎重選擇，分片規則的選擇，需要考慮資料的增長模式，資料的訪問模式，分片關聯性問題，以及分片擴容問題，最近的分片策略為範圍分片，列舉分片，一致性Hash分片，這幾種分片都有利於擴容 
原則四：儘量不要在一個事務中的SQL跨越多個分片，分散式事務一直是個不好處理的問題 
原則五：查詢條件儘量最佳化，儘量避免Select * 的方式，大量資料結果集下，會消耗大量頻寬和CPU資源，查詢儘量避免返回大量結果集，並且儘量為頻繁使用的查詢語句建立索引。 


如果某個表的資料有明顯的時間特徵，比如訂單、交易記錄等，則他們通常比較合適用時間範圍分片，因為具有時效性的資料，我們往往關注其近期的資料，查詢條件中往往帶有時間欄位進行過濾，比較好的方案是，當前活躍的資料，採用跨度比較短的時間段進行分片，而歷史性的資料，則採用比較長的跨度儲存。 
總體上來說，分片的選擇是取決於最頻繁的查詢SQL的條件，因為不帶任何Where語句的查詢SQL，會便利所有的分片，效能相對最差，因此這種SQL越多，對系統的影響越大，所以我們要儘量避免這種SQL的產生。