網上有很多介紹分庫分表的文章，方法很多：
分區表切分
垂直切分
水平切分
區間切分
取模切分
這里不細說
分庫分表簡單，但后期會帶來一系列的難題：
事務
Join
分頁
數據庫：
master和slave是一個主從架構
imagespider_db：[ImageSpider]項目采集回來的數據，不需要部署主從分離。
imageshow_db_1、imageshow_db_2、imageshow_db_3、imageshow_db_4:
四個分庫的結構一模一樣。(注意，分庫的個數最好是2的N次方，不然基因取模算法可能會失效)
t_users用戶表：
用戶登錄和注冊時，需要用name來定位分庫；查看用戶資料時，需要用uid定位分庫，
所以，把name的基因加入到uid中，uid的最后2bit為name的crc32的最后2bit，這樣通過uid和name都能定位到分庫。
t_images圖片表：
按 id % 4分庫，分頁時采用“禁止跳頁法”。
t_comments評論表：
id的最后2bit為imgid的2bit，保證一張圖片的所有評論和圖片切分到同一個數據庫中。
用戶評論時，t_images表的comment_count字段加1，因為是同一個數據庫，仍然可以使用事務處理；
所有評論都切分到同一個數據庫，分頁時可以使用傳統方法。
t_likes點贊表：
和t_comments表一樣，也使用imgid最后2bit作為分庫基因。
在某些場景下，使用基因切分法，把相關表都切分到同一個數據庫中，在后期的操作中仍然可以使用事務，Join等操作，
但可能會導致分庫數據不均衡。
ImageShow只是一個水平切分的例子，功能，代碼都很簡單，肯定不能涵蓋分庫分表的所有應用場景。
源碼