分庫分表之後如何通過非分片鍵操作

今天看到乙個場景，比如乙個表，表名字是award_use_risk，作用是記錄獎品使用的記錄，用作風控。表結構如下：

這個表，只是分庫，沒有分表，db分成4個庫，分別是db0-db4。

我的第一反應是根據terminal no或者prize guid，具體看業務邏輯進行分表操作，這樣增加、修改、刪除都可以通過分片演算法定位到哪個庫。

後來看到業務場景裡面，需要定時刪除前一天的風控資料，這種情況下，條件裡面只有時間，沒有分片鍵，如何定位每個庫呢？

梳理一下：

根據prize guid進行分片路由，比如prize guid%1024/256，結果0-3，正好我們是四個庫，沒有問題

如果刪除前一天的所有風控記錄，怎麼辦，這個時候沒有prize guid，如何分片？delete from award_use_risk where gmt_create 大約昨天，我們要的就是這個sql語句在每個庫執行一遍，不能路由，因為路由不確定哪個庫執行，哪個庫沒有執行。

為了確定刪除的時候在哪個庫，我們不能用prize guid，只能用確定的數字0-3去定位每個庫執行一遍，這樣我們的分片路由鍵就必須是乙個確定範圍的數字，0,1,2,3，稱之為data id。

在刪除的時候，for 迴圈，以此傳入0,1,2,3，就可以輪詢刪除每個庫裡面前一天的資料了。

那麼插入呢？我們用data id，每個風控記錄，都需要生成這個data id，我們就根據prize guid%1024/256，計算出data id，進行分庫分表。ok了。

上面的案例可以通過冗餘字段解決，但是對於一些不帶分片鍵的條件查詢，並不是通用方案，我們一起看看非分片鍵過濾，如何解決：

例如按照狀態和時間範圍來查詢訂單表 orders，常見的sql 這樣的。

這樣好處是**簡單，但是壞處顯而易見，在不帶分片欄位的情況下，中介軟體不知道資料具體都在哪個分片上，故而會將查詢sql以併發的形式發給所有的分片資料庫，造成了資料庫的效能下降明顯，嚴重影響了核心業務對資料庫的需求，而且在某些情況下還會導致記憶體溢位，雖然可以建立合適的索引提高效能。

mycat可以指定資料庫節點，多執行緒讀取每個資料節點，雖然提高了效能，但是效果並不理想。

計算機領域的問題，都可以通過分而治之或者增加一層解決。這個問題，我們為了提高效率，增大空間，比如訂單資訊表進行分庫分表之後，為了查詢買家訂單，我們需要根據買家id查詢，明顯不會走分片鍵，所以在

建立修改訂單的時候，另外建立乙個表，這個表按照買家id進行分庫分表，查詢的時候，根據買家id查詢到訂單id，然後再去訂單表找訂單資訊。流程如下：

這個方案可以，但是不夠通用，如果我們根據時間、狀態等資訊組合查詢呢？

我的思路就是監聽資料庫的變化，有很多中介軟體可以實現（canal+kafka），根據資料庫的binlog，

實時建立資料倉儲，把資料歸集在一起，方便查詢，避免分庫分表帶來的複雜性。

1.事務支援

分庫分表後，就成了分布式事務了。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的效能代價；如果由應用程式去協助控制，形成程式邏輯上的事務，又會造成程式設計方面的負擔。

2.複雜查詢

解決這個問題的一些方法：

全域性表

全域性表，也可看做是 "資料字典表"，就是系統中所有模組都可能依賴的一些表，為了避免跨庫join查詢，可以將這類表在每個資料庫中都儲存乙份。這些資料通常

很少會進行修改，所以也不擔心一致性的問題。

字段冗餘

利用空間換時間，為了效能而避免join查詢。例：訂單表儲存userid時候,也將username冗餘儲存乙份，這樣查詢訂單詳情時就不需要再去查詢"買家user表"了。

資料組裝

在系統層面，分兩次查詢。第一次查詢的結果集中找出關聯資料id，然後根據id發起第二次請求得到關聯資料。最後將獲得到的資料進行字段拼裝。

備註：1.目前營銷中心分庫分表後的id，並沒有用雪花演算法，而是乙個資料庫的sequence表記錄了id的next value，從而做到全域性不重複。配置如下：

2. 營銷中心的非分片鍵查詢？