Mongo分庫方案兩種形式分析：
1. mongo sharding方式：
1.1. 深翻頁的問題
舉例：當mongo的分片是5片時，分頁查詢（如果按照創建時間倒敘查詢）第一頁，每頁50條數據，則mongo sharding在每個分片上取50條數據，一共505條數據，然後進行彙總，計算出前50條正確數據作爲返回結果。如果是翻頁到1000頁，那麼mongo sharding需要從5個分片上分別查詢501000=5萬條條數據，然後彙總成5010005 = 25萬條數據，然後計算第1000頁的數據，，這樣系統會佔用很大的系統資源，很容易造成系統異常。這個問題暫時沒有什麼可以解決的辦法。
1.2. mongo sharding再平衡時，有可能查詢數據出現重複的問題
當mongo sharding根據 sharding key，將數據存入mongo的5個片（1，2，3，4，5）時，一般會產生5個分片數據不均勻的問題，假如1，2的分片數據較多，3，4，5的分片數據量較少，那麼mongo sharding再平衡策略會將1，2分片上的數據平衡到3，4，5分片上，如果此時數據正在進行平衡，那麼查詢1，2分片上的數據平衡到3，4，5的那部分的數據時，而且沒有命中索引的情況時，有可能出現重複數據的現象。現有的解決方式是，在晚上調用量少的時候進行數據平衡，白天數據訪問量大的時候關閉再數據平衡。
1.3. mongo分片擴展
分片不能夠無限擴大，實際使用中一般分成個位數分片，很難做到無限擴展。
1.4. sharding的key不能變更
sharding key 一旦指定，不可更改。更改之後，訪問數據的分片邏輯會變，導致服務不可用。
2. 採用物理分庫方式：
2.1 分庫要自己代碼實現
需要自己代碼中實現根據不同的context訪問不同的數據庫，即實現根據分庫的key，路由到不同的物理庫上。
2.2 不同的分庫交叉訪問問題
不能夠像mongo sharding那樣直接交叉訪問庫，如果要進行交叉訪問庫，只能在程序中自己實現。
2.3 負載均衡
mongo sharding內部實現了負載均衡，如果採用物理分成多個mongo庫，實現負載均衡需要自己代碼實現。
