如果你有先見之明的話，會給表名，存儲過程的名字加上前綴，例如論壇表命名為BBS_xxx，博客表命名為BLOG_xxx；這樣的話在分表處理時會比較容易一些。說到這兒也許你會想到外鍵約束怎麼辦，我的博客表，論壇帖子表都有用了User表的主鍵做外鍵呀。這個很容易處理，我們需要當機立斷的刪掉外鍵，這個當機立斷可能會帶來一些麻煩，我們來分析下可能會遇到一些什麼問題：
1. 分成多個庫，沒了外鍵了以前的inner join操作要跨庫嗎？
假定場景：博客表有對用戶表的外鍵引用，我們需要在首頁顯示博客列表，博客列表需要顯示用戶名和用戶id的信息
之前用戶表，博客表在一個庫裡面的時候我們可以通過外鍵inner join來取得用戶的關聯信息，現在用戶庫和博客庫被拆成了兩個庫，我想對跨庫做inner join說no；為什麼呢，因為這不適合擴展，假如有一天我們的業務量又增長了我們就需要把用戶庫挪到另外一台機器上，這要導致inner join跨服務器了，這顯然不是一個好辦法，那該怎麼辦呢？ 我有兩種方案，大家評判好壞：
1）做違反范式的設計，將用戶的不變信息用戶名和用戶id一起存在博客表中，讓用戶名冗余吧，這樣做可以保證取博客數據連帶用戶名時是非常高效率的
2）我們不再從數據庫中取用戶名的信息，改從緩存中取，我們可以在緩存中形成一個最近活躍的用戶數據池，當我們需要用戶名時從這個緩存區中去取。
目前在我的應用中用的是第一種方案，第二種更有伸縮性，第一種存冗余數據只能存用戶名，有時候只存用戶名就夠了，有時候可能會出現不夠的問題。
2. 如果用到了根據外鍵做的級聯刪除，那這是一個噩夢
對付這個問題，我的方案是修改程序，如果需要級聯刪除，在程序邏輯中完成，不要在數據庫做級聯刪除了，級聯刪除是一種隱含在數據庫中的邏輯，是一種不好的設計方案。
3. 觸發器也可能帶來和外鍵做級聯刪除同樣的麻煩，同樣的也是修改程序邏輯，代替這種數據庫級別的隱含邏輯。 也許你會說分庫之後一定會帶來性能的提高嗎？這個問題得具體分析，這要看你的服務器性能如何，如果分庫之後數據庫的cpu，io，內存的壓力依然很大；那麼您可以將分庫之後的其中某一個庫遷移到另外一台服務器上，讓兩台服務器分攤數據訪問的壓力，肯定會提升性能的。
最後說下，分庫分與不分是由數據量、性能要求決定的。下篇分表敬請期待！
