http://blog.csdn.net/zou274/archive/2009/04/18/4091036.aspx

http://www./topic/364016?page=4

ak478288:

簡單用戶表 tb_user: 
userid , username 

用戶詳細(xì)信息表 tb_userinfo 
userid , email , homepage , phone , address 

把用戶信息分開的目的就是保證經(jīng)常查詢的數(shù)據(jù)在一張表，其它信息放到另一張表 

論壇主題表 tb_bbs 
bbsid , userid , title , ip , repleycount , replyuserid , createtime , lastreplytime 

論壇內(nèi)容標(biāo) tb_bbs_content (此表可按照bbsid進(jìn)行分表存儲) 
bbsid , content; 

論壇回復(fù)表 tb_bbs_reply (此表可按照bbsid進(jìn)行分表存儲) 
replyid , bbsid , userid , content , replytime , ip 


說說我設(shè)計(jì)的想法 : 

論壇使用最多的功能為以下幾個(gè) 

一個(gè)話題列表頁面，例如 

select count(*) from tb_bbs; 查詢數(shù)量，用來分頁 

select * from tb_bbs order by lastreplytime desc limit ?,?; 

在列表中一般會顯示發(fā)帖人的基本信息，例如username 

在這里一般會使用以下的查詢方式: 

select * from tb_user u , tb_bbs b where u.userid=b.userid order by lastreplytime desc limit ?,?; 

如果連表操作壓力大的情況下，可以直接使用 

select * from tb_bbs order by lastreplytime desc limit ?,?; 

對于用戶信心可以根據(jù)userid去緩存中取數(shù)據(jù),這樣避免的與tb_bbs表的關(guān)聯(lián)查詢 


一個(gè)話題單頁 

對內(nèi)容分表，可看具體情況而定，例如 

bbsid是數(shù)字 

bbs_content根據(jù)bbsid末位進(jìn)行分表 

分為 
bbs_content0 , 
bbs_content1 , 
bbs_content2 , 
bbs_content3 , 
bbs_content4 , 
bbs_content5 , 
bbs_content6 , 
bbs_content7 , 
bbs_content8 , 
bbs_content9 

tb_bbs_reply可以分為 

tb_bbs_reply0 , 
tb_bbs_reply1 , 
tb_bbs_reply2 , 
tb_bbs_reply3 , 
tb_bbs_reply4 , 
tb_bbs_reply5 , 
tb_bbs_reply6 , 
tb_bbs_reply7 , 
tb_bbs_reply8 , 
tb_bbs_reply9 , 

例如bbsid=5687 

select * from tb_bbs where bbsid=5687 

//去緩存中取bbs_content相應(yīng)內(nèi)容,如果沒有就根據(jù)算法 

int tableIdx=modTable(5687); 

//tableIdx=7 

select * from tb_bbs_content7 where bbsid=5687; 

select * from tb_bbs_reply7 where bbsid=5687 order by replyid asc limit ?,? 

用戶信息從緩存中取或者 

select * from tb_bbs_reply7 r tb_user u,where bbsid=5687 adn r.userid=u.userid order by replyid asc limit ?,? 

基本的使用場景是這個(gè)樣子. 

里面所有對于分表的思想就是，盡量讓表文件大小達(dá)到最小化， 


把內(nèi)容與其它信息分開的好處就是可以讓每個(gè)表的文件最小化,對數(shù)據(jù)庫操作壓力會減小. 

這樣保證每張表數(shù)據(jù)量很小，操作速度會快，而且可以搭配緩存，把內(nèi)容根據(jù)情況進(jìn)行緩存，可以盡量很少訪問表數(shù)據(jù) 

對于高訪問量，不能只依賴于數(shù)據(jù)庫，還要配合緩存的使用，我在上述例子中使用的緩存只是做法一種，也許還有更好的 

對于上述分表方式也可以適用于分庫操作，這樣就降低了數(shù)據(jù)庫單庫的壓力，把壓力分散到各個(gè)機(jī)器 

我的做法就是盡量避免表關(guān)聯(lián) 

再就是對于sql語句盡量都保證索引有效，不能索引的sql，盡量采用能索引的高效方式解決 

有不妥的地方請指正

////////

z494627:

提高速度的關(guān)鍵: 
1.建立索引并在查詢時(shí)充分利用; 
2.避免使用關(guān)聯(lián),這樣避免整表掃描;使用關(guān)聯(lián)不如多次使用主鍵查詢來的快; 
3.一些處理的功能盡可能放到內(nèi)存中來做,比如組織主題和回復(fù); 
4.使用靜態(tài)頁面也是個(gè)不錯(cuò)的做法;

///////

這是延續(xù)了hibernate二級緩存的思想， 對于經(jīng)常更新的數(shù)據(jù)都設(shè)計(jì)成單獨(dú)表 
這樣可以最大程度的利用hibernate緩存 

1.分表存儲;
2.建立索引;SQL按所以查詢的速度還是很快的;
3.避免整表掃描;先讀取主題,在按照主題ID讀取回復(fù);再按照用戶ID讀取用戶;而不要使用關(guān)聯(lián);
4.使用緩存;