隨著業務越來越複雜，資料量越來越大，併發量越來越大，資料庫的效能越來越低。好不容易找運維申請了兩台機器，讓dba部署了幾個例項，想把一些業務庫拆分出來，卻發現拆不出來，擴不了容，尷尬！
因為資料庫強關聯在一起，無法通過增加資料庫例項擴容，就是乙個耦合的典型案例。
場景還原
有乙個公共使用者資料庫db_user，裡面table_user存放了通用的使用者資料：
table_user (uid, name, passwd, …)
在資料量比較小，併發量比較小，業務還沒有這麼複雜的時候，為了提高資源利用率（程式設計師才沒有考慮什麼資源利用率，更多的是圖方便），業務a把使用者個性化的資料也放在這個庫里：
table_a(uid, a業務的個性化屬性)
業務a有乙個需求，即要展現使用者公共屬性，又要展現業務a個性化屬性，程式設計師經常這麼實現的：
select * from table_user, table_a
where table_user.uid = table_a.uid
and table_user.uid = $uid
初期關聯查詢沒有任何問題，單條記錄訪問，命中索引，一次查詢所有資料，簡單高效。
如何產生各業務資料耦合？
通過join實現業務，導致通用表table_user和業務表table_a必須存在於乙個資料庫例項裡。
如果業務b也這麼做，業務c也這麼做，會導致公用業務，業務a，業務b，業務c都必須存在於乙個資料庫例項裡。
會產生什麼潛在問題呢？
假如a業務線上線了乙個新功能，不小心進行了全表掃瞄，導致資料庫cpu100%，資料庫例項效能下降，由於例項共用，通用業務，業務b和業務c都會受影響。
即某個業務線的資料庫效能急劇下降導致所有業務都受影響，這種耦合，歷史總是驚人的相似：
額，然而，這個理由，好像在大boss那解釋不通…
...
唉，加了幾台機器，加了幾個例項，然而並沒有什麼卵用，都耦合在乙個例項裡，完全擴不了容。
那，如何解除公共資料庫與業務資料庫的耦合？
第一步：公共資料訪問下沉服務化
還是上面的例子，當公共的user資料訪問服務化之後，依據服務化的原則：
第二步：垂直拆分，個性化資料訪問上浮
原來業務方：
服務化+垂直拆分後，變成兩次訪問：
兩種方式相比：
業務複雜，資料量大，併發老大，對擴充套件性要求更高的架構，一定是後者。
此時各業務有自己的庫，公共有公共的庫：
個性業務資料訪問垂直拆分，共性資料訪問服務化下沉
，只是乙個很小的優化點，但對於資料庫解耦卻是非常的有效。
希望大家每天收穫一點點，這樣架構就能美好一點點。
你痛過嗎，你見過乙個庫里耦合了幾百個表嗎？那幫轉下。
**:
耦合，緊耦合，松耦合，解耦
一 耦合 耦合是兩個或多個模組之間的相互關聯。在軟體工程中，兩個模組之間的耦合度越高，維護成本越高。因此，在系統架構的設計過程中，應減少各個模組之間的耦合度，以提高應用的可維護性。二 緊耦合 緊耦合架構本質是client server的模型，如下圖所示 優點是 架構簡單 設計簡單 開發周期短 能夠快...
程式設計的解耦和耦合
耦合 coupling 表示兩個子系統 或類 之間的關聯程度。當乙個子系統 或類 發生變化時對另乙個子系統 或類 的影響很小，則稱它們是鬆散耦合的 反之，如果變化的影響很大時，則稱它們是緊密耦合的。耦合的強弱取決於模組間接間的複雜性 引用模組的位置和資料的傳送方式等。解耦就是解除耦合關係。模組間有依...
耦合是什麼？如何做到解耦？
一 耦合 耦合指的是兩個類之間的聯絡的緊密程度 強耦合 類之間存在著直接關係 弱耦合 在兩個類的中間加入一層，將原來的直接關係變成間接關係，使得兩個類對中間層是強耦合，兩類之間變為弱耦合 二 解耦 1.什麼是解耦 在軟體工程中，降低耦合度即可以理解為解耦，也就是將強耦合變為弱耦合的過程。模組間有依賴...