sql2000的查詢結(jié)果進(jìn)行相關(guān)度排序，聽起來好象很吸引人，不過真的是可以實(shí)現(xiàn)的。 上午上網(wǎng)看到了一篇利用微軟index server來做全文查詢的文章（這個(gè)以前也看到過，在計(jì)算機(jī)管理中也自帶了這樣一個(gè)查詢功能）我的IIS默認(rèn)web服務(wù)器在g:/wwwroot下其中有10萬多的html文檔 測試：strSearch = 'SELECT DocTitle, Path, FileName, Characterization, Size,write,RANK' & _ ' FROM SCOPE()' & _ ' WHERE CONTAINS ('' & Request.Form('txtSearchFor') & '') ORDER BY RANK; desc' 還進(jìn)行了相關(guān)度的排序，我沒有做時(shí)間的具體開銷的計(jì)算，不過給人的感覺還可以接受，在翻頁的時(shí)候就非常快了。不過最大的缺點(diǎn)好象就是只能索引靜態(tài)頁面了。 下午我把以前的一個(gè)50多萬條記錄（主要是歌曲名和歌手名）的數(shù)據(jù)庫在sql2000做了索引，晚上就可以開始測試了。 測試一： 'select top 26 * from song1 where contains(songtitle,'愛')'，對(duì)結(jié)果沒有進(jìn)行任何的處理，只是按照ID的升續(xù)排列時(shí)間開銷基本上維持在0.016s，速度是很讓人滿意的，至少感覺不到慢。

測試二：利用rank值進(jìn)行了相關(guān)度的排序，'order by rank desc' or 'order by rank asc',查詢結(jié)果在排序的質(zhì)量上讓人滿意，都比較準(zhǔn)確的，不管是查詢時(shí)使用 or 或者and進(jìn)行多關(guān)鍵字的排序都還可以的，不過時(shí)間的開銷讓我受不了，居然在6s到8s之間，而且cpu也占用比較高 我看到網(wǎng)上其他的搜索的相關(guān)度排序都比較快的，開源的Lucene我沒有研究過，因?yàn)槲也欢甹ava。不過我想如果在索引的時(shí)候?qū)γ總€(gè)關(guān)鍵字進(jìn)行相關(guān)度的運(yùn)算查詢起來應(yīng)該不會(huì)慢的啊，這個(gè)我也感到郁悶。