目錄
ー：準備工作
數據庫集羣：一主兩從
數據庫高可用：不推薦，主從數據同步不一致問題。諮詢了一線公司的兄弟。千萬級數據量經過分表和主從讀寫分離後，完全扛得住。比如 1000萬 的表，切分 4表 之後也就單表 200多萬 。查詢速度並不慢
-
諮詢到的情況，是單表 1000萬 剛剛達到分表的界限。單表其實也可以支持。20 個字段左右。（數據量剛好達到分表分庫的情況）
-
主要是讀時延時。 千萬級數據主鍵查詢也就 1s ，其實也並不慢。如果沒命中索引。10s 左右。切分後單表大概 200 多萬數據。
-
要引入主鍵生成模塊。防止分表後，各表的主鍵衝突。（如果不符合，則分表方案作罷，既要保證主鍵的唯一性，數據要是從其他庫中導入不會有該問題）
-
主鍵查詢會增快，但是也就在 1s 內。看切分規則！
-
如果是 hash 切分，那全表查詢需要排序需要查詢所有的庫再排序，增加了複雜度。（只能儘量避免），既可能會更慢。且堆排序需要內存支持。不適合太大數據
-
如果按照範圍進行切分，則按索引查詢會很快。全查只需要每個表有序再進行合併即可。但是會產生的問題是查詢的範圍不均。可能會集中在一個區間。但是公司業務屬於導購這邊的業務，每個導購應該都是活躍的。應該查詢的都比較熱吧。建議採用這種分表的方式。切分規則較簡單易於配置和理解。排序的話只需要取某個庫的進行排序。（推薦）
-
-
-
需要引入保證數據庫的高可用的能力以及故障恢復的能力。建議引入 binlog 備份能力。需要 DBA 開發。引入一天一備，一週一備，一月一備的能力，以及每天的增量備份。(我只會全量備份 binlog)， DBA 那邊搞這個。倒是基本沒出過事只是出問題時候的保障
二：MyCat 出現的坑
-
以下的問題都是按數據庫已經按區間分表。切分規則如下，以自增的 id 主鍵進行 hash 分片。
-
mycat 目前只支持分庫 join ！不支持單庫分表 join 。坑。不知道怎麼搞。可能只能使用程序來控制。轉戰 sharding-jdbc
-
mycat 作爲數據源使用的表都需要在配置文件中配置
-
mycat 不支持配置文件的熱加載。需要重啓中間件。這期間可能打斷應用中執行的某些任務
問題一：非分片建查詢
正常查詢：根據分片主建查詢，映射中存在映射關係，正常路由到正確表進行查詢。
SELECT * FROM submeter WHERE id = 999;
除了 id 路由鍵之外的數據就需要三個庫都進行查詢了。因爲中間件不確定在哪個庫，之後還要進行合併的過程。所以基本杜絕了大量數據的非路由鍵的查詢
SELECT * FROM submeter WHERE qwe = 'qwe999';
explain SELECT * FROM submeter WHERE qwe = 'qwe999'; // MyCat 會返回重寫後的路由信息
dn1 SELECT * FROM submeter1 WHERE qwe = 'qwe999' LIMIT 100
dn1 SELECT * FROM submeter2 WHERE qwe = 'qwe999' LIMIT 100
dn1 SELECT * FROM submeter3 WHERE qwe = 'qwe999' LIMIT 100
前端一個查詢，落到庫中變爲三個查詢（只分了三個表）。佔用三個數據庫連接。如果分的多了，數據庫響應其他客戶端的能力變弱。
問題二：分頁問題
語句：默認是是按主鍵進行排序的
select * from submeter limit 2;
explain select * from submeter limit 2; // MyCat 會返回重寫後的路由信息
dn1 SELECT * FROM submeter1 LIMIT 2
dn1 SELECT * FROM submeter2 LIMIT 2
dn1 SELECT * FROM submeter3 LIMIT 2
引入問題：
- 還是一個查詢變多個查詢的問題。
- 分頁是按第一個 dataNode 返回的結果集爲準的。（現象就是多執行幾次。每次得到的結果集不同）
解決問題：
- 問題一無法解決
- 需要加入排序字段解決，比如 order by id 語句。三個結果集都查完之後使用堆排序進行結果集的整合。（帶入的問題是需要額外的引入排序機制，基本上排序都涉及到極高的時間複雜度），如果是使用 區間 進行拆分，則可以只拿其中一個查詢結果集交差
問題三：分頁問題再加入偏移量
語句：默認是是按主鍵進行排序的
select * from submeter order by id limit 5,2;
explain select * from submeter order by id limit 5,2;
dn1 SELECT * FROM submeter1 ORDER BY id LIMIT 0, 7
dn1 SELECT * FROM submeter2 ORDER BY id LIMIT 0, 7
dn1 SELECT * FROM submeter3 ORDER BY id LIMIT 0, 7
問題：
對於有 t 個 DB 節點的全分片 limit m, n 操作，Mycat 需要處理的數據量爲 (m+n)*t 個。比如實際應用中有 50 個 DB 節點，要執行 limit 1000,10 操作，則 Mycat 處理的數據量爲 50500 條，返回結果集爲 10，當偏移量更大時，內存和 CPU 資源的消耗則是數十倍增加。
解決問題：
看業務，這邊使用區間進行拆分，一般只需要一個結果集即可。每個數據都較活躍不會造成某個範圍分片區域過熱。
或者用 ES 的排序來解決大數據量的分頁問題。數據庫只提供詳情查詢。
三：結論
公司業務要求有多個列表，且列表需要多維度進行查詢，相同類型的數據還需要別的維度排序，根據上文可知。MyCat 中間件不適合做這些事情，所以轉用了 ES 作爲搜索引擎，屏蔽了對數據庫的複雜查詢，但是還是需要提供相應的產出數據的接口作爲兜底，以防 ES 丟失數據時對服務的保證。且根據其他服務來源的數據，該數據是以主鍵遞增的形式生成，並且每個 id 都很活躍，所以決定使用範圍切分的方法，屏蔽 hash 分片帶來的不易擴展等問題。因爲每條數據都很活躍，所以也不會產生範圍切分時某個分片請求過熱的問題。