1. 首先，“分布式”:是从业务的角度的概念。
"分布式”是从业务角度出发的：即当我们想着“注册”模块需要更新或者出问题了，那么我们不希望它影响存量用户的“登陆”和“下单”模块，这个时候，我们多希望他们不在一起多好，那么当我们真的这么做了，将各个业务模块都分开，ok，那这就是“分布式”了。
从数据库的发展历程来看，像什么数据库冷备热备、主从、双活、多活、集群等等，都与“分布式”不相关,与业务不相关，都是在“分布式”之前已经成熟应用的；
所以“分布式”与他们有什么关系？！ 没什么关系，你即可以“分布式”的同时，又双活，多活等等，现实也往往是同时应用的，分布式常常会搭配主从提供高可用数据库服务。
2.“分布式数据库”与“分布式应用”（这里撇开数据库垂直切分和水平切分）
其实从上面的概念所讲，分布式是业务一个概念，所以他跟数据库还是应用也并没有什么耦合关系，我们常说的"分布式数据库"其实是跟着"分布式应用"一起的，即当业务按模块分开之后，那么应用，以及其对应的数据库都统一分开了。
这里面就会有一个问题，当他们也都分开之后，那么我们的这些应用是一对一调用数据库吗？还是可以混合调用？
这里从历史的发展以及分布式划分的概念来讲，一定是一对一调用，即我们不应该在"登陆模块"中既调用"登陆数据库"，又调用"订单数据库"，所有这种调用应该通过应用间的相互调用，而不是一个应用可以访问多种不同的数据库，虽然我们可以这么做，但我们不应该这样做，因为如果你这样做了，那只能说明一个问题：即你并没有将你的业务模块划分好，并没有将它们尽量独立，尽量解耦 — 而这个恰恰是"分布式"设计最重要、最关键的地方，而你究竟用哪种技术去实现，这反倒是次要的。
从历史发展来看，也没有那种混搭调用数据源的，非常乱，根本不可管理。
3. "分布式数据库"具体细节（分布式的某一布来说）
大体来讲，"分布式数据库"可分为两大部分：垂直切分 和 水平切分。
a. 垂直切分：其实就是上面所说的按大模块分库；
b. 水平切分：一般是横向切分表，即分表。
也就是，当一张表越来越大，依然是有瓶颈存在，比如客户表，达到1个亿的数据，那么查询起来就是非常痛苦的一件事，这时候，将此大表水平切分成1000个小表，这样查询起来就可以很快定位，瓶颈解决了。
注：这里是说的就只拿分布式一步来说，即可以通过mycat实现垂直水平切分。 这里其实是一个应用服务访问了多个数据库。2中不考虑分库，3中不考虑分布式，这样与2看起来就不矛盾了。