之前在講表拆分的時候氛圍垂直拆分和水平拆分

垂直拆分的查詢其實不難，就是從單表變為了多表，而大部分情況下只是對主表的查詢多，從表的查詢會很少用到，這樣的情況下關聯查詢不需要太多的考慮

水平拆分之前講了大數據量的情況下根據歷史時間來查詢，那麽今天來說另外一種，還有一只是根據主鍵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月底上線，期待與大家見面！

網站平臺架構演變史（四） - 水平拆分的查詢