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

測(cè)試二：利用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)鍵字的排序都還可以的，不過(guò)時(shí)間的開(kāi)銷讓我受不了，居然在6s到8s之間，而且cpu也占用比較高 我看到網(wǎng)上其他的搜索的相關(guān)度排序都比較快的，開(kāi)源的Lucene我沒(méi)有研究過(guò)，因?yàn)槲也欢甹ava。不過(guò)我想如果在索引的時(shí)候?qū)γ總€(gè)關(guān)鍵字進(jìn)行相關(guān)度的運(yùn)算查詢起來(lái)應(yīng)該不會(huì)慢的啊，這個(gè)我也感到郁悶。