1. 首先，“分佈式”:是從業務的角度的概念。
"分佈式”是從業務角度出發的：即當我們想着“註冊”模塊需要更新或者出問題了，那麼我們不希望它影響存量用戶的“登陸”和“下單”模塊，這個時候，我們多希望他們不在一起多好，那麼當我們真的這麼做了，將各個業務模塊都分開，ok，那這就是“分佈式”了。
從數據庫的發展歷程來看，像什麼數據庫冷備熱備、主從、雙活、多活、集羣等等，都與“分佈式”不相關,與業務不相關，都是在“分佈式”之前已經成熟應用的；
所以“分佈式”與他們有什麼關係？！ 沒什麼關係，你即可以“分佈式”的同時，又雙活，多活等等，現實也往往是同時應用的，分佈式常常會搭配主從提供高可用數據庫服務。
2.“分佈式數據庫”與“分佈式應用”（這裏撇開數據庫垂直切分和水平切分）
其實從上面的概念所講，分佈式是業務一個概念，所以他跟數據庫還是應用也並沒有什麼耦合關係，我們常說的"分佈式數據庫"其實是跟着"分佈式應用"一起的，即當業務按模塊分開之後，那麼應用，以及其對應的數據庫都統一分開了。
這裏面就會有一個問題，當他們也都分開之後，那麼我們的這些應用是一對一調用數據庫嗎？還是可以混合調用？
這裏從歷史的發展以及分佈式劃分的概念來講，一定是一對一調用，即我們不應該在"登陸模塊"中既調用"登陸數據庫"，又調用"訂單數據庫"，所有這種調用應該通過應用間的相互調用，而不是一個應用可以訪問多種不同的數據庫，雖然我們可以這麼做，但我們不應該這樣做，因爲如果你這樣做了，那隻能說明一個問題：即你並沒有將你的業務模塊劃分好，並沒有將它們儘量獨立，儘量解耦 — 而這個恰恰是"分佈式"設計最重要、最關鍵的地方，而你究竟用哪種技術去實現，這反倒是次要的。
從歷史發展來看，也沒有那種混搭調用數據源的，非常亂，根本不可管理。
3. "分佈式數據庫"具體細節（分佈式的某一布來說）
大體來講，"分佈式數據庫"可分爲兩大部分：垂直切分 和 水平切分。
a. 垂直切分：其實就是上面所說的按大模塊分庫；
b. 水平切分：一般是橫向切分表，即分表。
也就是，當一張表越來越大，依然是有瓶頸存在，比如客戶表，達到1個億的數據，那麼查詢起來就是非常痛苦的一件事，這時候，將此大表水平切分成1000個小表，這樣查詢起來就可以很快定位，瓶頸解決了。
注：這裏是說的就只拿分佈式一步來說，即可以通過mycat實現垂直水平切分。 這裏其實是一個應用服務訪問了多個數據庫。2中不考慮分庫，3中不考慮分佈式，這樣與2看起來就不矛盾了。