例如:select count(*)from lui _ user _ base where t . user _ name like“% cs %”；
2.喜歡...“%”和“% ...”都是索引的，但是效率還是很低。
3，有人說用下面的sql，他的效率提高了10倍，但是在數據量小的時候。
select count(*)from lui _ user _ base where rowid in(select rowid from lui _ user _ base t where t . user _ name like“% cs %”)
我用100w跳數數據測試，效果壹般，但還是很慢。原因是:
select rowid from lui _ user _ base t where t . user _ name like“% cs %”？這條sql執行速度很快，相當快，但是放入來自lui _ user _ base where rowid in()的select count (*)後，效率會變得非常慢。
4、select count(*)from lui _ user _ base t where instr(t . user _ name，' cs ')& gt；0
這種查詢有效快捷，推薦使用。因為不太了解甲骨文的內部機制，所以只是解釋了壹下結果。
5.有人說用全文索引。我讀過了。步驟比較麻煩，但不失為壹個好方法。保留它以備後用:
麻省理工學院；
結束；
-優化
可變工單編號；
開始
DBMS_JOB。提交(:作業號，' CTX _ DDL . optimize _ index(' INX _ custom info _ ADDR _ DOCS ' '，'完整' ')；'，SYSDATE，' SYSDATE+1 ')；
提交；
結束；
其中，第壹個作業的SYSDATE+(1/24/4)表示每15分鐘同步壹次，第二個作業的SYSDATE+1表示每1天全面優化壹次。具體的時間間隔可以根據應用的需要來確定。
6、指標重構
重建索引將刪除原始索引，並且重新生成索引需要很長時間。
重建索引的語法如下:
在X_CUSTOMINFO_ADDR_DOCS重建中更改索引；
根據網上壹些用戶的體驗，oracle重建索引的速度也是比較快的。壹位用戶這樣描述它:
Oracle的全文檢索在建立和維護索引方面比ms sql server快得多。索引壹個有650，000條記錄的表只需要20分鐘，同步壹次只需要1分鐘。
因此，也可以考慮按作業定期重建索引。