一個困擾我良久的問題，在今天早上8：41分時基本解決。
     資料庫的資料量非常龐大，查詢速度極慢，建立索引後“=”搜尋速度問題解決，但是在搜尋的sql語句中大部分是用like，可是like '%XXX%'是不使用索引的，而like 'XXX%'則經過索引，求教曾經的老師、高階程式設計師也無用，在網站上搜索、求助，最終鎖定兩種辦法：1.全文索引。2.搜尋引擎。 但據說全文索引的速度也不盡人意，對GBK的支援也有些問題，暫且研究搜尋引擎，但發現搜尋引擎不是一時半刻可以研究透徹的東西，只得轉向全文索引，下面是建立全文索引的方法：
     (在某個表上建立文字索引之前，如果該表上沒有主鍵，必須為該表建立一個主鍵)
create index 文字索引名
       on 表名(要建文字索引的表字段)
indextype is ctxsys.context;

在建立文字索引用時比較長，要耐心等待...
建立完成後查詢測試：select * from table where CONTAINS(USERNAME,'可可')>0
     速度果然大幅提升，心想多天來的問題終於得到解決。但沒想到，在搜尋結果較多的時候.Count累加的速度慢了下來，索引也全部建立，解決辦法至今沒有發現，昨晚躺在床上翻來覆去，想到很多像論壇的搜尋中都限制了搜尋的關鍵字個數，這樣可以有效的控制查詢結果的數量，可以限制搜尋時輸入的關鍵字最少不得少於四個漢字。但轉眼一想不可行，因為庫中資料很有可能只有兩個字、三個字的名稱，這樣會造成搜尋結果不可靠...
     今天早上一大早就來到公司，開啟昨天在網上求助的帖子，回答人確實不少，提出了各種各樣的方法，可是我都曾嘗試過，都是行不通的，也許這個特殊專案的要求比較特別。靜下心仔細想想，我在See頁面需要的查詢其實大體可分為兩種，小範圍搜尋和大範圍搜尋，在以前的小範圍搜尋中速度是合格的，但是最近加入大範圍搜尋，則出現以下問題，但是加入全文索引後，大範圍的速度大幅度提高了，而小範圍的count卻出奇的慢。分析完成，很明顯，在小範圍搜尋的時候用普搜(同時可限制不得只輸入一個字)，而大範圍的時候用全文索引進行搜尋。立即按照此方案進行修改，終於...我希望的效果基本出現了。(但是大範圍搜尋時，速度較小範圍略慢，但應無大礙) 心情大爽！本一度以為要放棄此問題的.但最終尋得了解決辦法..雖然沒有《越獄》那樣驚險刺激，但解決問題後的心情也的確夠勁。
     接下來還有一個個的小問題，解決它們只是時間問題了...