如果你有先見之明的話，會給表名，存儲過程的名字加上前綴，例如論壇表命名為BBS_xxx，博客表命名為BLOG_xxx；這樣的話在分表處理時會比較容易一些。說到這兒也許你會想到外鍵約束怎么辦，我的博客表，論壇帖子表都有用了User表的主鍵做外鍵呀。這個很容易處理，我們需要當機立斷的刪掉外鍵，這個當機立斷可能會帶來一些麻煩，我們來分析下可能會遇到一些什么問題：

1. 分成多個庫，沒了外鍵了以前的inner join操作要跨庫嗎？

假定場景：博客表有對用戶表的外鍵引用，我們需要在首頁顯示博客列表，博客列表需要顯示用戶名和用戶id的信息

之前用戶表，博客表在一個庫里面的時候我們可以通過外鍵inner join來取得用戶的關聯信息，現在用戶庫和博客庫被拆成了兩個庫，我想對跨庫做inner join說no；為什么呢，因為這不適合擴展，假如有一天我們的業(yè)務量又增長了我們就需要把用戶庫挪到另外一臺機器上，這要導致inner join跨服務器了，這顯然不是一個好辦法，那該怎么辦呢？ 我有兩種方案，大家評判好壞：

1）做違反范式的設計，將用戶的不變信息用戶名和用戶id一起存在博客表中，讓用戶名冗余吧，這樣做可以保證取博客數據連帶用戶名時是非常高效率的

2）我們不再從數據庫中取用戶名的信息，改從緩存中取，我們可以在緩存中形成一個最近活躍的用戶數據池，當我們需要用戶名時從這個緩存區(qū)中去取。

目前在我的應用中用的是第一種方案，第二種更有伸縮性，第一種存冗余數據只能存用戶名，有時候只存用戶名就夠了，有時候可能會出現不夠的問題。

2. 如果用到了根據外鍵做的級聯刪除，那這是一個噩夢

對付這個問題，我的方案是修改程序，如果需要級聯刪除，在程序邏輯中完成，不要在數據庫做級聯刪除了，級聯刪除是一種隱含在數據庫中的邏輯，是一種不好的設計方案。

3. 觸發(fā)器也可能帶來和外鍵做級聯刪除同樣的麻煩，同樣的也是修改程序邏輯，代替這種數據庫級別的隱含邏輯。

也許你會說分庫之后一定會帶來性能的提高嗎？這個問題得具體分析，這要看你的服務器性能如何，如果分庫之后數據庫的cpu，io，內存的壓力依然很大；那么您可以將分庫之后的其中某一個庫遷移到另外一臺服務器上，讓兩臺服務器分攤數據訪問的壓力，肯定會提升性能的。

最后說下，分庫分與不分是由數據量、性能要求決定的。下篇分表敬請期待！

最新評論