之前在講表拆分的時候氛圍垂直拆分和水平拆分 垂直拆分的查詢其實不難，就是從單表變為了多表，而大部分情況下只是對主表的查詢多，從表的查詢會很少用到，這樣的情況下關聯查詢不需要太多的考慮 水平拆分之前講了大數據量的情況下根據歷史時間來查詢，那麼今天來說另外一種，還有一隻是根據主鍵id取模後根據這樣的規則 ...
之前在講表拆分的時候氛圍垂直拆分和水平拆分
垂直拆分的查詢其實不難，就是從單表變為了多表，而大部分情況下只是對主表的查詢多，從表的查詢會很少用到，這樣的情況下關聯查詢不需要太多的考慮
水平拆分之前講了大數據量的情況下根據歷史時間來查詢，那麼今天來說另外一種，還有一隻是根據主鍵id取模後根據這樣的規則把數據均勻分佈到不同的資料庫表中，一般可以以2、5、10來做，那麼分頁的時候怎麼做，用戶在查詢的時候是不知道你後臺怎麼查的，他只關心數據的顯示，比如我分頁顯示10條，那麼在後臺進去查詢的時候需要將"10/資料庫數量=實際對應每頁查詢數"，比如就用5好了，所有數據都是平均分佈到5個不同的資料庫中，那麼10/5=2，分頁的時候需要對這5個資料庫查詢，那麼就是 ' limt row, 2 '，最後合併5次查詢的數據來反饋給前端顯示。
這是實時的做法，如果不實時，採用緩存或者搜索引擎的時候，可以分別查詢一定的數據量來展示。舉個慄子，哪怕分頁有100多頁，一般用戶只看前10也，或者20頁的數據，那就用20頁，每頁顯示20條數據，20X20/5=80，那麼分別同步5個庫的80條數據，放入緩存或者搜索引擎中，來展示給用戶，這樣用戶在做查詢的時候就非常快，極少數情況下載20頁後的數據再去資料庫中查。
也許有人會問條件查詢、以及排序，如果直接查詢資料庫的話呢麽進行排序會比較難做，甚至不好做，而是用搜索引擎就能很好的解決這個問題。
其實還有一點沒講，會再寫1-2篇來結束這次的架構內邀會的總結。近期實在很忙，手上兩個產品都要做，抽空總結，公眾號更新頻率下降了十分抱歉；其中一個產品預期7月底上線，期待與大家見面！
