背景
大家在進行分庫分表的時候應該有碰到乙個問題，乙個資料需要根據兩種維度進行查詢，但是我們在進行分庫分表是只能根據一種維度進行。比如：使用者購買了商品產生了訂單，當使用者非常多的時候，我們會選擇訂單根據下單使用者的id進行分庫分表。但是這裡面存在乙個問題就是作為賣家要如何查詢我賣出的所有訂單呢？因為訂單是根據使用者id規則進行分庫分表的，賣家訂單查詢介面物理上是無法一次查詢出當前的訂單的，應該他分別分布在不同的訂單庫或者訂單表中的，有可能我查詢乙個訂單列表，需要跨非常多的表，這個樣效能是非常低效的。有沒一種有效的方法解決這個問題呢？
解決方案
那就是資料冗餘，之前提到過的datax 資料同步框架可以有效的幫我們解決這個問題，我們分別建立兩個訂單庫，乙個基於買家維度、乙個基於賣家維度，通過datax 把買家庫的訂單同步到賣家維度的訂單庫中，這樣就能夠很好的解決賣家查詢訂單跨庫的這個問題。當然這裡面還存在乙個缺陷就是datax並不是實時的機制，他是通過定時的機制進行資料同步的所以會存在一定的延遲，當然我們可以把定時的週期調整小一點，但是這樣會比較浪費效能。更加友好的解決方案還可以通過canal、otter。 otter是乙個分布式資料庫同步系統他是基於canal再次封裝開發的，當然canal也有他的優點就是定製化比較強，他可以和主流的kafka rocketmq進行整合，然後我們在去處理這塊資料同步的業務，這些都是很好的方案。最後還有一種方案就是基於cqrs的領域事件的思路進行的，領域事件有乙個好處就是乙個事件可以被多個消費者消費，這個是以往的rpc呼叫無法具備的。賣家訂單系統可以訂閱這個訂單建立事件，寫入訂單賣家維度資料庫中，也可以非常高效的解決這個問題。以上的方案其實都是非常合理的方案，個人還是更喜歡基於領域事件的形式進行同步，因為不需要再引入過多的外部元件，造成系統的負責度上公升。使用canal 、otter的方案我們都需要做資料庫的binglog同步操作，這個很多時候會被限制，我們壓根沒有許可權去配置這些東西。所以還是建議通過領域事件的方式解決以上的問題。
mysql 分表後如何排序 分庫分表的排序
分庫分表的排序 分庫分表的排序 1.對於單庫，冗餘乙個彙總所有資料表，用於全部資料的排序，但是當資料量大，彙總表將會成為瓶頸。這不是乙個很好的方案 2.無論單庫還是多個分庫，都由程式讀取需要資料並作排序。排序的幾種方式 大都是按時間排序的，如 分庫分表的排序 分庫分表的排序 1.對於單庫，冗餘乙個彙...
水平分庫分表後的分頁查詢
分庫後，分頁查詢按照時間time來排序order by。若查詢第x頁的資料，每頁y條。一共n個庫。步驟 將order by time offset x y 1 limit y，改寫成order by time offset 0 limit x y 1 y 服務層將改寫後的sql語句發往各個分庫 即每...
分庫，分表後連表查詢的問題解決方案
方案一 利用union，union all 方案二 建一張主表將你要連表查詢的字段放在其中，做好索引 你還記錄下使用者經常查詢的條件，把查出的資料快取，以便使用者經常呼叫。方案三 我們可以把經常要用到的資料寫到cache中,這樣以後要獲取的時候直接到cache裡拿。比如一天更新一次的情況 像德問的排...