转载一个知乎关于网站系统架构的帖子: 关于数据库该不该使用外健

https://www.zhihu.com/question/19600081/answer/94706401#comment-400660207

mark一下，以防原答主删帖，侵权私信我

Q 大家设计数据库时使用外键吗？

@林灿斌 的回答

我简单地画了一个最常见的中型网络服务的架构示意图：

用户的请求，通过前端的负载均衡分发到应用服务器上，应用服务器对于数据的请求，又通过数据的负载均衡分发的读写分离的数据库集群上（读写分离的从数据库通过二进制日志从主服务器同步数据）。

这种架构，对于系统开发的复杂度不会有什么明显的提升。

但是很容易可以注意到，这个架构下，负责写的数据库服务器，只有一个。如果用绿色圆饼代表服务器负载的话，加入约束的主服务器，insert、update、delete操作都会有更多的性能消耗。于是负责写入的主数据库服务器会很快遇到瓶颈。

根据木桶理论，我们可以知道，这个系统也遇到了瓶颈。

那么把负载最高的服务器上的干的活，转移到易于扩展的其他服务器上，可以有效提升整个系统的性能。

那么把 主数据库服务器（写） 上的约束转移到应用服务器上去做，就可以有效提升性能了——极端点的能转移就全部转移。

还有为了压榨 主数据库服务器（写） 上的一些性能，用GUID替代AutoIncrement作为主键的唯一性保障，同样也是这个道理。

这么做之后，我们可以观察到 主数据库服务器（写） 上的负载有了显著的降低，但是应用服务器的负载提升了，这时候怎么办呢？只要再加几台应用服务器就好了。

最后，再分享另一种的网络服务的系统架构：

这种情况下，把约束做到数据库里，就很方便了，降低了应用服务上逻辑层的复杂度。（有人要问了：为什么负载这么低啊？因为用户量少啊hhhhhhhhhh）

总之，加不加，还是看需求。

但是我个人倾向于把对性能的需求，放到易于扩展服务器迅速解决性能瓶颈的服务中。