分庫分表對老業務功能帶來的衝擊
當業務量發展到一定的程度時，不可避免的需要對資料進行分庫分表。以使用者的簽約資料為例，當使用者量很少時，單庫單錶是可以滿足的，但當使用者量達到某個級別，譬如億級，那麼單庫就會成為瓶頸，需要根據某種維度（譬如
userid
）來進行分庫分表。
分庫分表如何實現本文就不闡述了，可以參考一下**的
tddl
。本文主要闡述分庫分表過程中對老業務邏輯帶來的衝擊以及如何改造，因為有些原來單庫單錶中很容易實現的功能，一經分庫分表後，就變的很棘手，譬如：
a）根據主鍵
id（非
userid
）查詢簽約資訊：
b）插入資料時，
userid為空
c）聯表查詢，多個表不在同乙個庫里
1、首先來分析第乙個問題：根據主鍵
id（非
userid
）查詢簽約資訊。
由於根據
userid
來進行分庫，那麼根據
id是無法知道該去哪個庫查詢，當然可以採取全庫掃瞄，但一般這在效能上是無法接受的，違背了分庫分表的初衷。可以採取以下幾種方案：
1.1、
在進行查詢前，如果能拿到
userid
，則改造為根據
userid和id
兩個條件去查詢。
1.2、
如果拿不到
userid
，那麼對於老資料，需要建立乙個前置表，該錶儲存id和
userid
的對映關係(即：該錶只有兩個字段，id和userid)。根據
id查詢前，先根據
id去查詢前置表，得到
userid
，然後再根據
userid和id
兩個條件查詢。
分庫分表前
分庫分表後
需要注意的是，該前置表只需要儲存老資料的對映關係(該錶的資料由系統發布上線前對老資料遷移得到，發布上線後，不會再有新資料寫入)，對於新資料，在生成
id時，
id需要包含所屬庫和所屬表的標示，這樣根據
id查詢新資料時就可以直接路由到具體的庫和表了，不需要再查詢前置表。那麼根據
id如何區分新老資料呢，可以根據
id的長度（一般分庫後的
id位數會擴容）
2、接著分析第二個問題：插入資料時，
userid
此時為空
在分庫分表前，有些業務流程在執行過程中，插入資料時沒有分庫分表的維度資訊譬如
userid
，只有執行某個業務操作譬如使用者登陸後才能得到
userid
，然後更新這條記錄以補全
分庫分表前
那麼分庫分表後，在插入資料的那個時刻，就無法知道該把資料插入到哪個庫哪個表。針對這種情況，需要對插入資料的流程進行改造。
先將資料進行臨時儲存，譬如儲存在集中式快取（
tair
、memcache
等）等使用者登陸後拿到
userid
後，再從快取中查詢出資料，然後再插入資料到
db中。
分庫分表後
3、再來看第三個問題：聯表查詢，多個表不在同乙個庫里
對聯表查詢進行拆分，保證被拆分過後的原子查詢都落在相同的庫里。當然，對於左聯結或右聯結查詢，要特備注意拆分前後結果的一致性，很有可能會出現拆分後結果記錄數減少的情況，需要重點測試。
分表分庫後帶來問題（主鍵衝突）
主鍵衝突問題 分庫分表的環境中，資料分布在不同的分片上，不能再借助資料庫自增長特性直接生成，否則會造成不同分片上的資料表主鍵會重複。新增資料 主鍵生成中心 分庫決策中心 切換相應庫 執行新增 事務問題 在執行分庫分表之後，由於資料儲存到了不同的庫上，資料庫事務管理出現了困難。如果依賴資料庫本身的分布...
你分庫分表的姿勢對麼？ 詳談水平分庫分表
一 背景 提起分庫分表，對於大部分伺服器開發來說，其實並不是乙個新鮮的名詞。隨著業務的發展，我們表中的資料量會變的越來越大，欄位也可能隨著業務複雜度的公升高而逐漸增多，我們為了解決單錶的查詢效能問題，一般會進行分表操作。同時我們業務的使用者活躍度也會越來越高，併發量級不斷加大，那麼可能會達到單個資料...
基於Calcite製作分庫分表中介軟體 功能場景
使用calcite製作分庫分表中介軟體,在實現功能的過程中,存在著幾種用途,總得來說,有三種.例子1觀察此sql update person set firstname fred where lastname wilson calcite會把它編譯成類似下面的關係表示式 logicaltablemo...