Oracle提升查詢效率

做表與表的連接查詢時(shí)，大表在前，小表在后 ，就是記錄數(shù)少的作為后表

創(chuàng)新互聯(lián)建站是專業(yè)的克山網(wǎng)站建設(shè)公司，克山接單;提供成都網(wǎng)站建設(shè)、成都網(wǎng)站制作,網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行克山網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!

查詢條件中的限制條件要寫在表連接條件前

盡量使用索引的字段做為查詢條件

如何提升oracle大表查詢的效率??？

1、建索引。

2、減少表之間的關(guān)聯(lián)；

3、優(yōu)化sql

,盡量讓SQL很快的定位，不要走全表查詢，盡量走索引

4、簡化查詢的字段。

希望對你有用。

如何提升Oracle數(shù)據(jù)庫搜索效率

需要用索引來解決，索引的創(chuàng)建規(guī)則如下：

1、表的

主鍵

、

外鍵

必須有索引；

2、數(shù)據(jù)量超過300的表應(yīng)該有索引；

3、經(jīng)常與其他表進(jìn)行連接的表，在連接字段上應(yīng)該建立索引；

4、經(jīng)常出現(xiàn)在Where子句中的字段，特別是大表的字段，應(yīng)該建立索引；

5、索引應(yīng)該建在選擇性高的字段上；

6、索引應(yīng)該建在小字段上，對于大的文本字段甚至超長字段，不要建索引；

7、復(fù)合索引的建立需要進(jìn)行仔細(xì)分析；盡量考慮用單字段索引代替：

A、

正確選擇

復(fù)合索引中的主列字段，一般是選擇性較好的字段；

B、復(fù)合索引的幾個(gè)字段是否經(jīng)常同時(shí)以AND方式出現(xiàn)在Where子句中？單字段查詢是否極少甚至沒有？如果是，則可以建立復(fù)合索引；否則考慮單字段索引；

C、如果復(fù)合索引中包含的字段經(jīng)常單獨(dú)出現(xiàn)在Where子句中，則分解為多個(gè)單字段索引；

D、如果復(fù)合索引所包含的字段超過3個(gè)，那么仔細(xì)考慮其必要性，考慮減少復(fù)合的字段；

E、如果既有單字段索引，又有這幾個(gè)字段上的復(fù)合索引，一般可以刪除復(fù)合索引；

8、頻繁進(jìn)行

數(shù)據(jù)操作

的表，不要建立太多的索引；

9、刪除無用的索引，避免對執(zhí)行計(jì)劃造成負(fù)面影響；

以上是一些普遍的建立索引時(shí)的判斷依據(jù)。一言以蔽之，索引的建立必須慎重，對每個(gè)索引的必要性都應(yīng)該經(jīng)過仔細(xì)分析，要有建立的依據(jù)。因?yàn)樘嗟乃饕c不充分、不正確的索引對性能都毫無益處：在表上建立的每個(gè)索引都會增加存儲開銷，索引對于插入、刪除、更新操作也會增加處理上的開銷。另外，過多的復(fù)合索引，在有單字段索引的情況下，一般都是沒有

存在價(jià)值

的；相反，還會降低數(shù)據(jù)增加刪除時(shí)的性能，特別是對頻繁更新的表來說，負(fù)面影響更大。

如何提高oracle模糊查詢的性能？

1、使用兩邊加‘%’號的查詢，Oracle是不通過索引的，所以查詢效率很低。

例如：select count(*) from lui_user_base t where t.user_name like '%cs%';

2、like '...%'和 like'%...'雖然走了索引，但是效率依然很低。

3、有人說使用如下sql，他的效率提高了10倍，但是數(shù)據(jù)量小的時(shí)候

select count(*) from lui_user_base where rowid in (select rowid from lui_user_base t where t.user_name like '%cs%')

我拿100w跳數(shù)據(jù)做了測試，效果一般，依然很慢，原因：

select rowid from lui_user_base t where t.user_name like '%cs%' ? 這條sql執(zhí)行很快，那是相當(dāng)?shù)目欤欠诺絪elect count(*) from lui_user_base where rowid in（）里后，效率就會變的很慢了。

4、select count(*) from lui_user_base t where instr(t.user_name,'cs') 0

這種查詢效果很好，速度很快，推薦使用這種。因?yàn)槲覍racle內(nèi)部機(jī)制不是很懂，只是對結(jié)果做了一個(gè)說明。

5、有人說了用全文索引，我看了，步驟挺麻煩，但是是個(gè)不錯(cuò)的方法，留著備用：

對cmng_custominfo 表中的address字段做全文檢索：

1，在oracle9201中需要創(chuàng)建一個(gè)分詞的東西：

BEGIN

ctx_ddl.create_preference ('SMS_ADDRESS_LEXER', 'CHINESE_LEXER');

--ctx_ddl.create_preference ('my_lexer', 'chinese_vgram_lexer'); 不用

end;

2，創(chuàng)建全文檢索：

CREATE INDEX INX_CUSTOMINFO_ADDR_DOCS ON cmng_custominfo(address) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS ('LEXER SMS_ADDRESS_LEXER');

3，查詢時(shí)候，使用：

select * from cmng_custominfo where contains (address, '金色新城')1;

4，需要定期進(jìn)行同步和優(yōu)化：

同步：根據(jù)新增記錄的文本內(nèi)容更新全文搜索的索引。

begin

ctx_ddl.sync_index('INX_CUSTOMINFO_ADDR_DOCS');

end;

優(yōu)化：根據(jù)被刪除記錄清除全文搜索索引中的垃圾

begin

ctx_ddl.optimize_index('INX_CUSTOMINFO_ADDR_DOCS', 'FAST');

end;

5，采用job做步驟4中的工作：

1)該功能需要利用oracle的JOB功能來完成

因?yàn)閛racle9I默認(rèn)不啟用JOB功能，所以首先需要增加ORACLE數(shù)據(jù)庫實(shí)例的JOB配置參數(shù):

job_queue_processes=5

重新啟動oracle數(shù)據(jù)庫服務(wù)和listener服務(wù)。

2)同步 和 優(yōu)化

--同步 sync:

variable jobno number;

BEGIN

DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.sync_index(''INX_CUSTOMINFO_ADDR_DOCS'');',

SYSDATE, 'SYSDATE + (1/24/4)');

commit;

END;

--優(yōu)化

variable jobno number;

begin

DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.optimize_index(''INX_CUSTOMINFO_ADDR_DOCS'',''FULL'');', SYSDATE, 'SYSDATE + 1');

commit;

END;

其中， 第一個(gè)job的SYSDATE + (1/24/4)是指每隔15分鐘同步一次，第二個(gè)job的SYSDATE + 1是每隔1天做一次全優(yōu)化。具體的時(shí)間間隔，可以根據(jù)應(yīng)用的需要而定。

6，索引重建

重建索引會刪除原來的索引，重新生成索引，需要較長的時(shí)間。

重建索引語法如下：

ALTER INDEX INX_CUSTOMINFO_ADDR_DOCS REBUILD;

據(jù)網(wǎng)上一些用家的體會，oracle重建索引的速度也是比較快的，有一用家這樣描述：

Oracle 的全文檢索建立和維護(hù)索引要比ms sql server都要快得多，筆者的65萬記錄的一個(gè)表建立索引只需要20分鐘，同步一次只需要1分鐘。

因此，也可以考慮用job的辦法定期重建索引。