mark一下，以防原答主刪帖，侵權私信我

@林燦斌 的回答

我簡單地畫了一個最常見的中型網路服務的架構示意圖：

使用者的請求，通過前端的負載均衡分發到應用伺服器上，應用伺服器對於資料的請求，又通過資料的負載均衡分發的讀寫分離的資料庫叢集上（讀寫分離的從資料庫通過二進位制日誌從主伺服器同步資料）。

這種架構，對於系統開發的複雜度不會有什麼明顯的提升。

但是很容易可以注意到，這個架構下，負責寫的資料庫伺服器，只有一個。如果用綠色圓餅代表伺服器負載的話，加入約束的主伺服器，insert、update、delete操作都會有更多的效能消耗。於是負責寫入的主資料庫伺服器會很快遇到瓶頸。

根據木桶理論，我們可以知道，這個系統也遇到了瓶頸。

那麼把負載最高的伺服器上的乾的活，轉移到易於擴充套件的其他伺服器上，可以有效提升整個系統的效能。

那麼把 主資料庫伺服器（寫） 上的約束轉移到應用伺服器上去做，就可以有效提升效能了——極端點的能轉移就全部轉移。

還有為了壓榨 主資料庫伺服器（寫） 上的一些效能，用GUID替代AutoIncrement作為主鍵的唯一性保障，同樣也是這個道理。

這麼做之後，我們可以觀察到 主資料庫伺服器（寫） 上的負載有了顯著的降低，但是應用伺服器的負載提升了，這時候怎麼辦呢？只要再加幾臺應用伺服器就好了。

最後，再分享另一種的網路服務的系統架構：

這種情況下，把約束做到資料庫裡，就很方便了，降低了應用服務上邏輯層的複雜度。（有人要問了：為什麼負載這麼低啊？因為使用者量少啊hhhhhhhhhh）

總之，加不加，還是看需求。

但是我個人傾向於把對效能的需求，放到易於擴充套件伺服器迅速解決效能瓶頸的服務中。