一個緊急查詢的改進思路

今天下午有一個緊急需求，是輔助業務部門做一個緊急查詢，既然說緊急查詢，那麼肯定業務上需要加急處理，那麼很快就需要找到我們DBA來幫忙了。
需求的情況是，需要根據某一個使用者的標識（比如手機號)來定位對應使用者的id,可能同一個身份證號，可以註冊多個不同的id。
根據資料的情況，在系統中已經做了分庫分表。情況類似下面的形式。

比如說資料分成了12個使用者，每個使用者中都有一個account_delta的表，但是每個使用者中的資料完全不同，然後每3個使用者對一個物理資料庫，所以基本就是4個分庫，12個使用者。
然後存在一個公共庫的資料，這個部分也是一個概要資訊，就是使用者id的一個繫結關係，是放在了一個公共庫中，也就意味著這個表沒有做分庫分表。
現在正如紅色箭頭所示，傳入了對應的標識欄位，需要做緊急查詢，這就意味著需要在這4個分庫12個使用者中做一個全範圍查詢。
而且比較要命的提供的查詢條件是非索引欄位，那麼只能做全表，所以12個使用者一個一個來查，然後merge起來，人肉hadoop，實在是緊急處理不了。
這個時候可以參考的一個地方就是我們存在一個統計庫，這個統計庫中會定時同步這些賬號庫中的這部分資料，目前是採用增量重新整理的方式，所以在統計庫中的結構如下：

統計庫中目前是建立了12個物化檢視，和源庫中的12個基表是類似的。然後對於開發同事來說，就是一個簡單的account_delta，即一個簡單的view。
在大多數的場景使用中沒有碰到什麼明顯的效能問題。
所以這個問題就可以轉化為下面的形式

這個時候這些查詢就可以直接在統計庫中完成，而不用一個一個庫的去逐個嘗試，因為目前統計庫中的資料是一天一次增量重新整理，如果覺得資料不夠新，可以再做一次增量重新整理即可。
所以這些工作都可以在統計庫中完成，對於原本的這些分庫沒有任何的壓力和負載。而且速度也是大幅度提高。
然後查到對應的使用者id之後，需要再一次做一個關聯查詢，就是和公共庫中的data_bind關聯，得到最後需要的資料，這個data_bind在統計庫中沒有做同步，而且本身也沒有做分庫分表。
但是值得一提的是這個表中的使用者id有對應的索引，所以在公共庫中按照使用者id來查詢，效能也還是不錯的。
然後就這樣簡單分析了問題之後，在統計庫中查詢，因為是全表掃描，然後再開個並行，分分鐘就會得出結果，然後把返回的使用者id和公共庫的data_bind關聯起來，很快就能得到最後的結果。
所以看似簡單枯燥的日常問題處理，如果多一些改進思路，那麼自己也會輕鬆許多。