⑴ 怎麼使用 基於oracle的sql優化
（1） 選擇最有效率的表名順序(只在基於規則的優化器中有效)：
ORACLE的解析器按照從右到左的順序處理FROM子句中的表名，FROM子句中寫在最後的表(基礎表 driving table)將被最先處理，在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎表。如果有3個以上的表連接查詢, 那就需要選擇交叉表(intersection table)作為基礎表, 交叉表是指那個被其他表所引用的表.
（2） WHERE子句中的連接順序．：
ORACLE採用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾.
（3） SELECT子句中避免使用 『 * 『：
ORACLE在解析的過程中, 會將'*' 依次轉換成所有的列名, 這個工作是通過查詢數據字典完成的, 這意味著將耗費更多的時間
（4） 減少訪問資料庫的次數：
ORACLE在內部執行了許多工作: 解析SQL語句, 估算索引的利用率, 綁定變數 , 讀數據塊等；
（5） 在SQL*Plus , SQL*Forms和Pro*C中重新設置ARRAYSIZE參數, 可以增加每次資料庫訪問的檢索數據量 ,建議值為200
（6） 使用DECODE函數來減少處理時間：
使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表.
（7） 整合簡單,無關聯的資料庫訪問：
如果你有幾個簡單的資料庫查詢語句,你可以把它們整合到一個查詢中(即使它們之間沒有關系)
（8） 刪除重復記錄：
最高效的刪除重復記錄方法 ( 因為使用了ROWID)例子：
DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)
FROM EMP X WHERE X.EMP_NO = E.EMP_NO);
（9） 用TRUNCATE替代DELETE：
當刪除表中的記錄時,在通常情況下, 回滾段(rollback segments ) 用來存放可以被恢復的信息. 如果你沒有COMMIT事務,ORACLE會將數據恢復到刪除之前的狀態(准確地說是恢復到執行刪除命令之前的狀況) 而當運用TRUNCATE時, 回滾段不再存放任何可被恢復的信息.當命令運行後,數據不能被恢復.因此很少的資源被調用,執行時間也會很短. (譯者按: TRUNCATE只在刪除全表適用,TRUNCATE是DDL不是DML)
（10） 盡量多使用COMMIT：
只要有可能,在程序中盡量多使用COMMIT, 這樣程序的性能得到提高,需求也會因為COMMIT所釋放的資源而減少:
COMMIT所釋放的資源:
a. 回滾段上用於恢復數據的信息.
b. 被程序語句獲得的鎖
c. redo log buffer 中的空間
d. ORACLE為管理上述3種資源中的內部花費
（11） 用Where子句替換HAVING子句：
避免使用HAVING子句, HAVING 只會在檢索出所有記錄之後才對結果集進行過濾. 這個處理需要排序,總計等操作. 如果能通過WHERE子句限制記錄的數目,那就能減少這方面的開銷. (非oracle中)on、where、having這三個都可以加條件的子句中，on是最先執行，where次之，having最後，因為on是先把不符合條件的記錄過濾後才進行統計，它就可以減少中間運算要處理的數據，按理說應該速度是最快的，where也應該比having快點的，因為它過濾數據後才進行sum，在兩個表聯接時才用on的，所以在一個表的時候，就剩下where跟having比較了。在這單表查詢統計的情況下，如果要過濾的條件沒有涉及到要計算欄位，那它們的結果是一樣的，只是where可以使用rushmore技術，而having就不能，在速度上後者要慢如果要涉及到計算的欄位，就表示在沒計算之前，這個欄位的值是不確定的，根據上篇寫的工作流程，where的作用時間是在計算之前就完成的，而having就是在計算後才起作用的，所以在這種情況下，兩者的結果會不同。在多表聯接查詢時，on比where更早起作用。系統首先根據各個表之間的聯接條件，把多個表合成一個臨時表後，再由where進行過濾，然後再計算，計算完後再由having進行過濾。由此可見，要想過濾條件起到正確的作用，首先要明白這個條件應該在什麼時候起作用，然後再決定放在那裡
（12） 減少對表的查詢：
在含有子查詢的SQL語句中,要特別注意減少對表的查詢.例子：
SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECT
TAB_NAME,DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)
（13） 通過內部函數提高SQL效率.：
復雜的SQL往往犧牲了執行效率. 能夠掌握上面的運用函數解決問題的方法在實際工作中是非常有意義的
（14） 使用表的別名(Alias)：
當在SQL語句中連接多個表時, 請使用表的別名並把別名前綴於每個Column上.這樣一來,就可以減少解析的時間並減少那些由Column歧義引起的語法錯誤.
（15） 用EXISTS替代IN、用NOT EXISTS替代NOT IN：
在許多基於基礎表的查詢中,為了滿足一個條件,往往需要對另一個表進行聯接.在這種情況下, 使用EXISTS(或NOT EXISTS)通常將提高查詢的效率. 在子查詢中,NOT IN子句將執行一個內部的排序和合並. 無論在哪種情況下,NOT IN都是最低效的 (因為它對子查詢中的表執行了一個全表遍歷). 為了避免使用NOT IN ,我們可以把它改寫成外連接(Outer Joins)或NOT EXISTS.
例子：
（高效）SELECT * FROM EMP (基礎表) WHERE EMPNO > 0 AND EXISTS (SELECT 『X' FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = 『MELB')
(低效)SELECT * FROM EMP (基礎表) WHERE EMPNO > 0 AND DEPTNO IN(SELECT DEPTNO FROM DEPT WHERE LOC = 『MELB')
（16） 識別'低效執行'的SQL語句：
雖然目前各種關於SQL優化的圖形化工具層出不窮,但是寫出自己的SQL工具來解決問題始終是一個最好的方法：
SELECT EXECUTIONS , DISK_READS, BUFFER_GETS,
ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2) Hit_radio,
ROUND(DISK_READS/EXECUTIONS,2) Reads_per_run,
SQL_TEXT
FROM V$SQLAREA
WHERE EXECUTIONS>0
AND BUFFER_GETS > 0
AND (BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8
ORDER BY 4 DESC;
（17） 用索引提高效率：
索引是表的一個概念部分,用來提高檢索數據的效率，ORACLE使用了一個復雜的自平衡B-tree結構. 通常,通過索引查詢數據比全表掃描要快. 當ORACLE找出執行查詢和Update語句的最佳路徑時, ORACLE優化器將使用索引. 同樣在聯結多個表時使用索引也可以提高效率. 另一個使用索引的好處是,它提供了主鍵(primary key)的唯一性驗證.。那些LONG或LONG RAW數據類型, 你可以索引幾乎所有的列. 通常, 在大型表中使用索引特別有效. 當然,你也會發現, 在掃描小表時,使用索引同樣能提高效率. 雖然使用索引能得到查詢效率的提高,但是我們也必須注意到它的代價. 索引需要空間來存儲,也需要定期維護, 每當有記錄在表中增減或索引列被修改時, 索引本身也會被修改. 這意味著每條記錄的INSERT , DELETE , UPDATE將為此多付出4 , 5 次的磁碟I/O . 因為索引需要額外的存儲空間和處理,那些不必要的索引反而會使查詢反應時間變慢.。定期的重構索引是有必要的.：
ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>
（18） 用EXISTS替換DISTINCT：
當提交一個包含一對多表信息(比如部門表和雇員表)的查詢時,避免在SELECT子句中使用DISTINCT. 一般可以考慮用EXIST替換, EXISTS 使查詢更為迅速,因為RDBMS核心模塊將在子查詢的條件一旦滿足後,立刻返回結果. 例子：
(低效):
SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E
WHERE D.DEPT_NO = E.DEPT_NO
(高效):
SELECT DEPT_NO,DEPT_NAME FROM DEPT D WHERE EXISTS ( SELECT 『X'
FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO);
（19） sql語句用大寫的；因為oracle總是先解析sql語句，把小寫的字母轉換成大寫的再執行
（20） 在java代碼中盡量少用連接符「＋」連接字元串！
（21） 避免在索引列上使用NOT 通常，
我們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函數相同的影響. 當ORACLE」遇到」NOT,他就會停止使用索引轉而執行全表掃描.
（22） 避免在索引列上使用計算．
WHERE子句中，如果索引列是函數的一部分．優化器將不使用索引而使用全表掃描．
舉例:
低效：
SELECT … FROM DEPT WHERE SAL * 12 > 25000;
高效:
SELECT … FROM DEPT WHERE SAL > 25000/12;
（23） 用>=替代>
高效:
SELECT * FROM EMP WHERE DEPTNO >=4
低效:
SELECT * FROM EMP WHERE DEPTNO >3
兩者的區別在於, 前者DBMS將直接跳到第一個DEPT等於4的記錄而後者將首先定位到DEPTNO=3的記錄並且向前掃描到第一個DEPT大於3的記錄.
（24） 用UNION替換OR (適用於索引列)
通常情況下, 用UNION替換WHERE子句中的OR將會起到較好的效果. 對索引列使用OR將造成全表掃描. 注意, 以上規則只針對多個索引列有效. 如果有column沒有被索引, 查詢效率可能會因為你沒有選擇OR而降低. 在下面的例子中, LOC_ID 和REGION上都建有索引.
高效:
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE LOC_ID = 10
UNION
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE REGION = 「MELBOURNE」
低效:
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE LOC_ID = 10 OR REGION = 「MELBOURNE」
如果你堅持要用OR, 那就需要返回記錄最少的索引列寫在最前面.
（25） 用IN來替換OR
這是一條簡單易記的規則，但是實際的執行效果還須檢驗，在ORACLE8i下，兩者的執行路徑似乎是相同的．
低效:
SELECT…. FROM LOCATION WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30
高效
SELECT… FROM LOCATION WHERE LOC_IN IN (10,20,30);
（26） 避免在索引列上使用IS NULL和IS NOT NULL
避免在索引中使用任何可以為空的列，ORACLE將無法使用該索引．對於單列索引，如果列包含空值，索引中將不存在此記錄. 對於復合索引，如果每個列都為空，索引中同樣不存在此記錄.如果至少有一個列不為空，則記錄存在於索引中．舉例: 如果唯一性索引建立在表的A列和B列上, 並且表中存在一條記錄的A,B值為(123,null) , ORACLE將不接受下一條具有相同A,B值（123,null）的記錄(插入). 然而如果所有的索引列都為空，ORACLE將認為整個鍵值為空而空不等於空. 因此你可以插入1000 條具有相同鍵值的記錄,當然它們都是空! 因為空值不存在於索引列中,所以WHERE子句中對索引列進行空值比較將使ORACLE停用該索引.
低效: (索引失效)
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;
高效: (索引有效)
SELECT … FROM DEPARTMENT WHERE DEPT_CODE >=0;
（27） 總是使用索引的第一個列：
如果索引是建立在多個列上, 只有在它的第一個列(leading column)被where子句引用時,優化器才會選擇使用該索引. 這也是一條簡單而重要的規則，當僅引用索引的第二個列時,優化器使用了全表掃描而忽略了索引
（28） 用UNION-ALL 替換UNION ( 如果有可能的話)：
當SQL語句需要UNION兩個查詢結果集合時,這兩個結果集合會以UNION-ALL的方式被合並, 然後在輸出最終結果前進行排序. 如果用UNION ALL替代UNION, 這樣排序就不是必要了. 效率就會因此得到提高. 需要注意的是，UNION ALL 將重復輸出兩個結果集合中相同記錄. 因此各位還是要從業務需求分析使用UNION ALL的可行性. UNION 將對結果集合排序,這個操作會使用到SORT_AREA_SIZE這塊內存. 對於這塊內存的優化也是相當重要的. 下面的SQL可以用來查詢排序的消耗量
低效：
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = '31-DEC-95'
UNION
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = '31-DEC-95'
高效:
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = '31-DEC-95'
UNION ALL
SELECT ACCT_NUM, BALANCE_AMT
FROM DEBIT_TRANSACTIONS
WHERE TRAN_DATE = '31-DEC-95'
（29） 用WHERE替代ORDER BY：
ORDER BY 子句只在兩種嚴格的條件下使用索引.
ORDER BY中所有的列必須包含在相同的索引中並保持在索引中的排列順序.
ORDER BY中所有的列必須定義為非空.
WHERE子句使用的索引和ORDER BY子句中所使用的索引不能並列.
例如:
表DEPT包含以下列:
DEPT_CODE PK NOT NULL
DEPT_DESC NOT NULL
DEPT_TYPE NULL
低效: (索引不被使用)
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_TYPE
高效: (使用索引)
SELECT DEPT_CODE FROM DEPT WHERE DEPT_TYPE > 0
（30） 避免改變索引列的類型.:
當比較不同數據類型的數據時, ORACLE自動對列進行簡單的類型轉換.
假設 EMPNO是一個數值類型的索引列.
SELECT … FROM EMP WHERE EMPNO = 『123'
實際上,經過ORACLE類型轉換, 語句轉化為:
SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(『123')
幸運的是,類型轉換沒有發生在索引列上,索引的用途沒有被改變.
現在,假設EMP_TYPE是一個字元類型的索引列.
SELECT … FROM EMP WHERE EMP_TYPE = 123
這個語句被ORACLE轉換為:
SELECT … FROM EMP WHERETO_NUMBER(EMP_TYPE)=123
因為內部發生的類型轉換, 這個索引將不會被用到! 為了避免ORACLE對你的SQL進行隱式的類型轉換, 最好把類型轉換用顯式表現出來. 注意當字元和數值比較時, ORACLE會優先轉換數值類型到字元類型
（31） 需要當心的WHERE子句:
某些SELECT 語句中的WHERE子句不使用索引. 這里有一些例子.
在下面的例子里, (1)『!=' 將不使用索引. 記住, 索引只能告訴你什麼存在於表中, 而不能告訴你什麼不存在於表中. (2) 『||'是字元連接函數. 就象其他函數那樣, 停用了索引. (3) 『+'是數學函數. 就象其他數學函數那樣, 停用了索引. (4)相同的索引列不能互相比較,這將會啟用全表掃描.
（32） a. 如果檢索數據量超過30%的表中記錄數.使用索引將沒有顯著的效率提高.
b. 在特定情況下, 使用索引也許會比全表掃描慢, 但這是同一個數量級上的區別. 而通常情況下,使用索引比全表掃描要塊幾倍乃至幾千倍!
（33） 避免使用耗費資源的操作:
帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啟動SQL引擎
執行耗費資源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序. 通常, 帶有UNION, MINUS , INTERSECT的SQL語句都可以用其他方式重寫. 如果你的資料庫的SORT_AREA_SIZE調配得好, 使用UNION , MINUS, INTERSECT也是可以考慮的, 畢竟它們的可讀性很強
（34） 優化GROUP BY:
提高GROUP BY 語句的效率, 可以通過將不需要的記錄在GROUP BY 之前過濾掉.下面兩個查詢返回相同結果但第二個明顯就快了許多.
低效:
SELECT JOB , AVG(SAL)
FROM EMP
GROUP JOB
HAVING JOB = 『PRESIDENT'
OR JOB = 『MANAGER'
高效:
SELECT JOB , AVG(SAL)
FROM EMP
WHERE JOB = 『PRESIDENT'
OR JOB = 『MANAGER'
GROUP JOB
⑵ Oracle資料庫對SQL查詢做了哪些優化
這么大的問題？ 太大了。 說清楚一本書了。簡單說 後台的優化處理器，會對 執行計劃，做處理，會分析當前日誌裡面的數據結構，預估出適合的執行計劃。磁碟存儲等都和查詢無關，是自身的結構，最多勉強說對主鍵都自動加了索引而已。索引原理樓主自己去看吧，當做一張表就行了。 不過現在oracle 也開始研究雲存儲，畢竟是趨勢，過兩年估計會部分實現。雲存儲可以先看看 hadoop。 執行計劃又和你當前資料庫默認配置有關，具體去看hint吧。
⑶ oracle sql優化涉及哪些原理
B 樹索引（B-Tree索引）
B樹索引是我們在oracle資料庫中最常用的索引，在詳細介紹訪問方法之前，我們看一下B-TREE索引的結構（圖片來源網路）
oracle的B樹索引就好像一顆長到的樹，他包含兩種類型，一種是索引分支塊（根節點塊，分支節點塊）一種是索引葉子塊（葉子節點塊）。分節點用來搜索，葉子節點用來存儲數據。根節點存儲索引的低層分支節點的數據。 由於所有的葉子節點均會自動的存儲成相同的深度，所以稱為「平 衡樹索引」， 故此，從任何葉子處檢索數據消耗的時間都是相同的。
對於分支節點塊（包括根節點塊）來說，其所包含的索引條目都是按照順序排列的（預設是升序排列，也可以在創建索引時指定為降序排列）。每個索引條目（也可以叫做每條記錄）都具有兩個欄位。第一個欄位表示當前該分支節點塊下面所鏈接的索引塊中所包含的最小鍵值；第二個欄位為四個位元組，表示所鏈接的索引塊的地址，該地址指向下面一個索引塊。 比如從上圖一可以看到，對於根節點塊來說，包含三條記錄，分別為（0 B1）、（500 B2）、（1000 B3），它們指向三個分支節點塊。其中的0、500和1000分別表示這三個分支節點塊所鏈接的鍵值的最小值。而B1、B2和B3則表示所指向的三個分支節點塊的地址。在一個分支節點塊中 所能容納的記錄 行數由數據塊大小以及索引鍵值的長度決定。
對於葉子節點塊來說，其所包含的索引條目與分支節點一樣，都是按照順序排列的（預設是升序排列，也可以在創建索引時指定為降序排列）。每個索引條目（也可以叫做每條記錄）也具有兩個欄位。第一個欄位表示索引的鍵值，對於單列索引來說是一個值；而對於多列索引來說則是多個值組合在一起的。第二個欄位表示鍵值所對應的記錄行的ROWID，該ROWID是記錄行在表裡的物理地址。
當用戶創建索引時，Oracle 取得所有被索引列的數據並進行排序，之後將排序後索引值和與此值相對應的 rowid 按照從下到上的順序載入到索引中。例如，以下語句：
[html] view plain print?在CODE上查看代碼片派生到我的代碼片
CREATE INDEX employees_last_name ON employees(last_name);
Oracle 先將 employees 表按 last_name 列排序，再將排序後的 列及相應的 rowid 按從下到上的順序載入到索引中。使用此索引時，Oracle 可以快速地搜索已排序的 last_name 值，並使用相應的 rowid 去定位包含用戶所查找的 last_name 值的數據行。
在一個平衡樹索引中，最底層的索引塊(葉塊)存儲了被索引的數據值，以及對應的
rowid。葉塊之間以雙向鏈表的形式相互連接。位於葉塊之上的分支塊中包含了
指向下層索引塊的指針。
接下來介紹一個索引查詢的流程，從上往下，第一層為根節點，第二層為分支節點，第三層為葉子節點（包含了列值和rowid）。比如我們的條件為where=29，(補充說明如果被索引的列存儲的是字元數據，那麼索引值為這些字元數據在當前資料庫字元集中的二進制值)就從跟節點開始查詢，29在0-500中，指向分支節點最左邊第一個分支節點塊（也就是B1），就B1中去找，發現29在0-200中，指向葉子節點的L1，於是在L1中找到29的值和響應的rowid。如果只查找索引列的值，就不用根據rowid去表中查找了，如果還要查找值29這行的其他列的值就得根據rowid去表裡查查詢（這個過程叫做回表查詢）。葉子節點還有個雙向鏈表（如圖）。在通過索引進行范圍掃描時會起作用，比如要查找值29-700，如果當查找到值29的時候，不就會再從跟節點開始查找其他的值，而是根據本葉子節點鏈表的指向去查找其他的值。
⑷ oracle資料庫中的instr的具體用法，在網上搜了很多，最終還是不明白，請教高手解釋。
首先，你運行下這句
selectinstr('123,456',',')fromal這個就是要查找逗號在123,456中的位置，結果是4，這個你應該明白吧，就是左數第4位是逗號
然後。這句
selectinstr('123,456,789',',')fromal結果還是4，因為後邊不加參數的話，就代表oracle要從最左端起，找第一個逗號，所以還是4，當你想查第二個逗號的位置的時候
selectinstr('123,456,789',',',5)fromal後邊多了一個5，也就是以5為起始位，開始找第一個逗號，所以最後結果就是8，也就是你要找的第二個逗號的位置了
4個參數
selectinstr('123,456,789',',',1,2)fromal就是代表從第一位開始取，取第二個逗號的位置，結果是8，如果2換成3的話，因為不存在第三個逗號，所以返回0
⑸ oracle 優化SQL問題
試試這樣
select t.acct_month,
a.area_desc,
t.acct_no,
t.acct_name acct_name_all,
case
when length(t.acct_name) > 6 then
substr(t.acct_name, 0, 6) || '...'
else
substr(t.acct_name, 0, 6)
end as acct_name,
t.cust_no,
t.cust_name cust_name_all,
else substr(t.cust_name, 0, 6) end as cust_name,
t.user_no,
t.user_name user_name_all,
case
when length(t.channel_desc) > 8 then
substr(t.channel_desc, 0, 8) || '...'
else
substr(t.channel_desc, 0, 8)
end as channel_desc,
t.user_dinner,
t.user_dinner_desc user_dinner_desc_all,
case
when length(t.user_dinner_desc) > 8 then
substr(t.user_dinner_desc, 0, 8) || '...'
else
substr(t.user_dinner_desc, 0, 8)
end as user_dinner_desc,
t.bus_grp_no,
t.bus_grp_desc bus_grp_desc_all,
case
when length(t.bus_grp_desc) > 8 then
substr(t.bus_grp_desc, 0, 8) || '...'
else
substr(t.bus_grp_desc, 0, 8)
end as bus_grp_desc,
t.link_tel_no,
t.user_address user_address_all,
else substr(t.user_address, 0, 8) end as user_address,
t.acct_income,
t.mou,
t.remark remark_all,
case
when length(t.remark) > 8 then
substr(t.remark, 0, 8) || '...'
else
substr(t.remark, 0, 8)
end as remark,
a.AREA_NO FACT_AREA_ID,
a.DESCRIPTION AREA_DESC,
a.IDX_NO SORT_ID,
a.AREA_NO AREA_ID
from dm.ODS_DETAIL_G_INCOME_USER_M t,
ODSCODE.DMCODE_AREA a
where t.AREA_NO = a.FACT_AREA_ID
and t.AREA_NO = '188'
and a.area_no = '188'
and t.acct_month = '201002'
order by ACCT_INCOME desc
⑹ 如何更好的使用Oracle全文索引
不使用Oracle text功能,也有很多方法可以在Oracle資料庫中搜索文本.可以使用標準的INSTR函數和LIKE操作符實現。
SELECT *FROM mytext WHERE INSTR (thetext, 'Oracle') > 0;
SELECT * FROM mytext WHERE thetext LIKE '%Oracle%';
有很多時候，使用instr和like是很理想的, 特別是搜索僅跨越很小的表的時候.然而通過這些文本定位的方法將導致全表掃描,對資源來說消耗比較昂貴,而且實現的搜索功能也非常有限，因此對海量的文本數據進行搜索時，建議使用oralce提供的全文檢索功能 建立全文檢索的步驟步驟一 檢查和設置資料庫角色首先檢查資料庫中是否有CTXSYS用戶和CTXAPP腳色。如果沒有這個用戶和角色，意味著你的資料庫創建時未安裝intermedia功能。你必須修改資料庫以安裝這項功能。 默認安裝情況下，ctxsys用戶是被鎖定的，因此要先啟用ctxsys的用戶。 步驟二 賦權 在ctxsys用戶下把ctx_ddl的執行許可權賦於要使用全文索引的用戶，例：
grant execute on ctx_ddl to pomoho;
步驟三 設置詞法分析器(lexer)
Oracle實現全文檢索，其機制其實很簡單。即通過Oracle專利的詞法分析器(lexer),將文章中所有的表意單元(Oracle 稱為 term)找出來，記錄在一組 以dr$開頭的表中，同時記下該term出現的位置、次數、hash 值等信息。檢索時，Oracle 從這組表中查找相應的term，並計算其出現頻率，根據某個演算法來計算每個文檔的得分(score),即所謂的『匹配率』。而lexer則是該機制的核心，它決定了全文檢索的效率。Oracle 針對不同的語言提供了不同的 lexer, 而我們通常能用到其中的三個：
n basic_lexer: 針對英語。它能根據空格和標點來將英語單詞從句子中分離，還能自動將一些出現頻率過高已經失去檢索意義的單詞作為『垃圾』處理，如if , is 等，具有較高的處理效率。但該lexer應用於漢語則有很多問題，由於它只認空格和標點，而漢語的一句話中通常不會有空格，因此，它會把整句話作為一個 term,事實上失去檢索能力。以『中國人民站起來了』這句話為例，basic_lexer 分析的結果只有一個term ,就是『中國人民站起來了』。此時若檢索『中國』，將檢索不到內容。
n chinese_vgram_lexer: 專門的漢語分析器，支持所有漢字字元集(ZHS16CGB231280 ZHS16GBK ZHT32EUC ZHT16BIG5 ZHT32TRIS ZHT16MSWIN950 ZHT16HKSCS UTF8 )。該分析器按字為單元來分析漢語句子。『中國人民站起來了』這句話，會被它分析成如下幾個term: 『中』，『中國』，『國人』，『人民』，『民站』，『站起』，起來』，『來了』，『了』。可以看出，這種分析方法，實現演算法很簡單，並且能實現『一網打盡』，但效率則是差強人意。
n chinese_lexer: 這是一個新的漢語分析器，只支持utf8字元集。上面已經看到，chinese vgram lexer這個分析器由於不認識常用的漢語詞彙，因此分析的單元非常機械，像上面的『民站』，『站起』在漢語中根本不會單獨出現，因此這種term是沒有意義的，反而影響效率。chinese_lexer的最大改進就是該分析器 能認識大部分常用漢語詞彙，因此能更有效率地分析句子，像以上兩個愚蠢的單元將不會再出現，極大 提高了效率。但是它只支持 utf8, 如果你的資料庫是zhs16gbk字元集，則只能使用笨笨的那個Chinese vgram lexer.
如果不做任何設置，Oracle 預設使用basic_lexer這個分析器。要指定使用哪一個lexer, 可以這樣操作：
第一． 當前用戶下下建立一個preference(例：在pomoho用戶下執行以下語句)
exec ctx_ddl.create_preference ('my_lexer', 'chinese_vgram_lexer');
第二． 在建立全文索引索引時，指明所用的lexer:
CREATE INDEX myindex ON mytable(mycolumn) indextype is ctxsys.context
parameters('lexer my_lexer');
這樣建立的全文檢索索引，就會使用chinese_vgram_lexer作為分析器。
步驟四 建立索引
通過以下語法建立全文索引
CREATE INDEX [schema.]index on [schema.]table(column) INDEXTYPE IS ctxsys.context [ONLINE]
LOCAL [(PARTITION [partition] [PARAMETERS('paramstring')]
[, PARTITION [partition] [PARAMETERS('paramstring')]])]
[PARAMETERS(paramstring)] [PARALLEL n] [UNUSABLE];
例：
CREATE INDEX ctx_idx_menuname ON pubmenu(menuname)
indextype is ctxsys.context parameters('lexer my_lexer')
步驟五 使用索引
使用全文索引很簡單，可以通過：
select * from pubmenu where contains(menuname,'上傳圖片')>0
全文索引的種類
建立的Oracle Text索引被稱為域索引(domain index)，包括4種索引類型：
l CONTEXT
2 CTXCAT
3 CTXRULE
4 CTXXPATH
依據你的應用程序和文本數據類型你可以任意選擇一種。
對多欄位建立全文索引
很多時候需要從多個文本欄位中查詢滿足條件的記錄，這時就需要建立針對多個欄位的全文索引，例如需要從pmhsubjects(專題表)的 subjectname(專題名稱)和briefintro(簡介)上進行全文檢索，則需要按以下步驟進行操作：
Ø 建議多欄位索引的preference
以ctxsys登錄，並執行：
EXEC ctx_ddl.create_preference(' ctx_idx_subject_pref',
'MULTI_COLUMN_DATASTORE');
Ø 建立preference對應的欄位值(以ctxsys登錄)
EXEC ctx_ddl.set_attribute(' ctx_idx_subject_pref ','columns','subjectname,briefintro');
Ø 建立全文索引
CREATE INDEX ctx_idx_subject ON pmhsubjects(subjectname)
INDEXTYPE ISctxsys.CONTEXT PARAMETERS('DATASTORE ctxsys.ctx_idx_subject_pref lexer my_lexer')
Ø 使用索引
select * from pmhsubjects where contains(subjectname,'李宇春')>0
全文索引的維護
對於CTXSYS.CONTEXT索引，當應用程序對基表進行DML操作後，對基表的索引維護是必須的。索引維護包括索引同步和索引優化。
在索引建好後，我們可以在該用戶下查到Oracle自動產生了以下幾個表：(假設索引名為myindex)：
DR$myindex$I、DR$myindex$K、DR$myindex$R、DR$myindex$N其中以I表最重要，可以查詢一下該表，看看有什麼內容：
SELECT token_text, token_count FROM dr$i_rsk1$I WHERE ROWNUM <= 20;
這里就不列出查詢接過了。可以看到，該表中保存的其實就是Oracle 分析你的文檔後，生成的term記錄在這里，包括term出現的位置、次數、hash值等。當文檔的內容改變後，可以想見這個I表的內容也應該相應改變，才能保證Oracle在做全文檢索時正確檢索到內容(因為所謂全文檢索，其實核心就是查詢這個表)。這就用到sync(同步) 和 optimize(優化)了。
同步(sync): 將新的term 保存到I表；
優化(optimize): 清除I表的垃圾，主要是將已經被刪除的term從I表刪除。
當基表中的被索引文檔發生insert、update、delete操作的時候，基表的改變並不能馬上影響到索引上直到同步索引。可以查詢視圖 CTX_USER_PENDING查看相應的改動。例如：
SELECT pnd_index_name, pnd_rowid,
TO_CHAR (pnd_timestamp, 'dd-mon-yyyy hh24:mi:ss') timestamp
FROM ctx_user_pending;
該語句的輸出類似如下：
PND_INDEX_NAME PND_ROWID TIMESTAMP
------------------------------ ------------------ --------------------
MYINDEX AAADXnAABAAAS3SAAC 06-oct-1999 15:56:50
同步和優化方法: 可以使用Oracle提供的ctx_ddl包同步和優化索引
一. 對於CTXCAT類型的索引來說， 當對基表進行DML操作的時候，Oracle自動維護索引。對文檔的改變馬上反映到索引中。CTXCAT是事務形的索引。
索引的同步
在對基表插入，修改，刪除之後同步索引。推薦使用sync同步索引。語法：
ctx_ddl.sync_index(
idx_name IN VARCHAR2 DEFAULT NULL
memory IN VARCHAR2 DEFAULT NULL,
part_name IN VARCHAR2 DEFAULT NULL
parallel_degree IN NUMBER DEFAULT 1);
idx_name 索引名稱
memory 指定同步索引需要的內存。默認是系統參數DEFAULT_INDEX_MEMORY 。
指定一個大的內存時候可以加快索引效率和查詢速度，且索引有較少的碎片
part_name 同步哪個分區索引。
parallel_degree 並行同步索引。設置並行度。
例如：
同步索引myindex:Exec ctx_ddl.sync_index ('myindex');
實施建議：建議通過oracle的job對索引進行同步
索引的優化
經常的索引同步將會導致你的CONTEXT索引產生碎片。索引碎片嚴重的影響了查詢的反應速度。你可以定期優化索引來減少碎片，減少索引大小，提高查詢效率。
當文本從表中刪除的時候，Oracle Text標記刪除的文檔，但是並不馬上修改索引。因此，就的文檔信息占據了不必要的空間，導致了查詢額外的開銷。你必須以FULL模式優化索引，從索引中刪除無效的舊的信息。這個過程叫做垃圾處理。當你經常的對表文本數據進行更新，刪除操作的時候，垃圾處理是很必要的。
exec ctx_ddl.optimize_index ('myidx', 'full');
實施建議：每天在系統空閑的時候對全文索引進行相應的優化，以提高檢索的效率
P.S.定時優化索引
3.定時優化同步域索引
創建定時任務，定期優化和同步域索引
SQL> create or replace procere hsp_sync_index as
2 begin
3 ctx_ddl.sync_index('id_cont_msg');
4 end;
5 /
Procere created.
Elapsed: 00:00:00.08
SQL> VARIABLE jobno number;
SQL> BEGIN
2 DBMS_JOB.SUBMIT(:jobno,'hsp_sync_index();',
3 SYSDATE, 'SYSDATE + (1/24/4)');
4 commit;
5 END;
6 /
PL/SQL procere successfully completed.
Elapsed: 00:00:00.27
SQL> create or replace procere hsp_optimize_index as
2 begin
3 ctx_ddl.optimize_index('id_cont_msg','FULL');
4 end;
5 /
SQL> VARIABLE jobno number;
SQL> BEGIN
2 DBMS_JOB.SUBMIT(:jobno,'hsp_optimize_index();',
3 SYSDATE, 'SYSDATE + 1');
4 commit;
5 END;
6 /
Procere created.
Elapsed: 00:00:00.03
PL/SQL procere successfully completed.
Elapsed: 00:00:00.02
SQL>
⑺ oracle 優化 instr 替換 =
這兩者不等價啊，前者是查位置，得到的值是位置，數字型，後者就是全部字元串是否等於『測試』
⑻ 執行一下Oracle SQL時，慢如蝸牛，如何優化
這樣給出的SQL沒有人可以幫助你優化，如果你真的希望有人可以幫助你，你需要將這個SQL的執行計劃和你的優化器模式貼出來，這樣才可以給你一點建議，
⑼ SQL語句優化 oracle
select /*+ leading(a) use_hash(b) */ a.a1,a.a2,......,b.name
from ht.hupat a,b
where a.no = b.no(+)
試試這個。目標是現先對a做全表掃描，因為你沒有條件，全表掃描效率最高。
然後b也做全表掃描。b應該是代碼表吧。a表應該是大表，每條記錄嵌套循環查找b表次數太多，導致代價太高，所以也全表掃描b表，
最後做哈希連接。
你看看執行計劃，得到上面描述的執行計劃就行了。否則可以自己調整hint，得到合適的執行計劃為止。
⑽ oracle中如何優化sql語句的，用什麼方法
可以使用ADDM哦，執行後可以幫助分析SQL性能以及給出修改建議