今天下午有乙個緊急需求，是輔助業務部門做乙個緊急查詢，既然說緊急查詢，那麼肯定業務上需要加急處理，那麼很快就需要找到我們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關聯起來，很快就能得到最後的結果。
所以看似簡單枯燥的日常問題處理，如果多一些改進思路，那麼自己也會輕鬆許多。
關於複雜查詢的乙個基本思路
先化繁為簡，再步步整合 create table areas aid int primary key,atitle varchar 20 pid int insert into areas values 130000 河北省 null 130100 石家莊市 130000 130400 邯鄲市 13...
乙個保密思路
如果你機子被入侵，那麼你最擔心的是什麼？那麼怎麼保護自己呢？這個時候乞求防毒軟體 防火牆，恐怕早沒什麼效果。基於上面的擔心考慮，我想出乙個不是萬能的辦法 1 寫乙個程式，感染本機內除系統目錄外的全部檔案，或者感染你指定的機密檔案。2 程式會自動的在所有源 檔案中插入特定 函式。3 本級每次啟動建立多...
Thunk 技術的乙個改進
thunk 技術的乙個改進 摘要 介紹了 thunk 技術中如何避免直接寫機器碼。關鍵字 thunk 機器碼 this指標 thunk技術，一般認為是在程式中直接構造出可執行 的技術 在正常情況下，這是編譯器的任務 深度探索c 物件模型 中對這個詞的 有過考證 在中文版的162頁 說thunk是kn...