ー：準備工作
二：mycat 出現的坑
三：結論
資料庫集群：一主兩從
資料庫高可用：不推薦，主從資料同步不一致問題。諮詢了一線公司的兄弟。千萬級資料量經過分表和主從讀寫分離後，完全扛得住。比如1000萬的表，切分4表之後也就單錶200多萬。查詢速度並不慢
諮詢到的情況，是單錶1000萬剛剛達到分表的界限。單錶其實也可以支援。20個字段左右。（資料量剛好達到分表分庫的情況）
主要是讀時延時。 千萬級資料主鍵查詢也就1s，其實也並不慢。如果沒命中索引。10s左右。切分後單錶大概200多萬資料。
要引入主鍵生成模組。防止分表後，各表的主鍵衝突。（如果不符合，則分表方案作罷，既要保證主鍵的唯一性，資料要是從其他庫中匯入不會有該問題）
主鍵查詢會增快，但是也就在1s內。看切分規則！
如果是hash切分，那全表查詢需要排序需要查詢所有的庫再排序，增加了複雜度。（只能盡量避免），既可能會更慢。且堆排序需要記憶體支援。不適合太大資料
如果按照範圍進行切分，則按索引查詢會很快。全查只需要每個表有序再進行合併即可。但是會產生的問題是查詢的範圍不均。可能會集中在乙個區間。但是公司業務屬於導購這邊的業務，每個導購應該都是活躍的。應該查詢的都比較熱吧。建議採用這種分表的方式。切分規則較簡單易於配置和理解。排序的話只需要取某個庫的進行排序。（推薦）
需要引入保證資料庫的高可用的能力以及故障恢復的能力。建議引入binlog備份能力。需要dba開發。引入一天一備，一周一備，一月一備的能力，以及每天的增量備份。(我只會全量備份 binlog)，dba那邊搞這個。倒是基本沒出過事只是出問題時候的保障
問題一：非分片建查詢
正常查詢：根據分片主建查詢，對映中存在對映關係，正常路由到正確表進行查詢。
select * from submeter where id = 999;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分片帶來的不易擴充套件等問題。因為每條資料都很活躍，所以也不會產生範圍切分時某個分片請求過熱的問題。
面試 資料庫 中介軟體
lru是redis唯一支援的 演算法 no eviction 不刪除策略 對於所有的key allkeys lru 刪除最近訪問頻率低的key allkeys random 隨機刪除一部分key 對於設定expire volatile lru 刪除最近訪問頻率低的key volatile rando...
mysql proxy資料庫中介軟體架構
一 mysql proxy簡介 mysql proxy是mysql官方提供的mysql中介軟體服務，上游可接入若干個mysql client，後端可連線若干個mysql server。它使用mysql協議，任何使用mysql client的上游無需修改任何 即可遷移至mysql proxy上。mys...
mysql proxy資料庫中介軟體架構
一 mysql proxy簡介 mysql proxy是mysql官方提供的mysql中介軟體服務，上游可接入若干個mysql client，後端可連線若干個mysql server。它使用mysql協議，任何使用mysql client的上游無需修改任何 即可遷移至mysql proxy上。mys...