ORACLE數據庫優化


  開發都離不開數據,對數據庫的熟悉程度可以為我們省去很多麻煩,我們必須先了解一下數據庫。

  一個事務本質上有四個特點ACID:

  Atomicity原子性

  Consistency一致性

  Isolation隔離性

  Durability耐久性

  悲觀鎖和樂觀鎖的區別

  悲觀鎖(Pessimistic Lock):

  每次拿數據的時候都會擔心會被別人修改(疑心重很悲觀),所以每次在拿數據的時候都會上鎖。確保自己使用的過程中不會被別人訪問,自己使用完后再解鎖。期間需要訪問該數據的都會等待。

  樂觀鎖(Optimistic Lock):

  每次拿數據的時候都完全不擔心會被別人修改(心態好很樂觀),所以每次在拿數據的時候都不會上鎖。但是在更新數據的時候去判斷該期間是否被別人修改過(使用版本號等機制),期間該數據可以隨便被其他人讀取。兩種鎖各有優缺點,不能單純的定義哪個好於哪個。樂觀鎖比較適合數據修改比較少,讀取比較頻繁的場景,即使出現了少量的沖突,這樣也省去了大量的鎖的開銷,故而提高了系統的吞吐量。但是如果經常發生沖突(寫數據比較多的情況下),上層應用不不斷的retry,這樣反而降低了性能,對於這種情況使用悲觀鎖就更合適

  Left join、right join、inner join區別

  left join   :左連接,返回左表中所有的記錄以及右表中連接字段相等的記錄。

  right join :右連接,返回右表中所有的記錄以及左表中連接字段相等的記錄。

  inner join :內連接,又叫等值連接,只返回兩個表中連接字段相等的行。

  full join :外連接,返回兩個表中的行:left join + right join

  cross join :結果是笛卡爾積,就是第一個表的行數乘以第二個表的行數。

  SQL優化

  根據自己學習,使用的經驗,分享一些優化方法,希望您能夠幫助到大家。

  數據庫有個高速緩沖的概念,這個高速緩沖呢就是存放執行過的SQL語句,那數據庫在執行sql語句的時候要做很多工作,例如解析sql語句, 估算索引利用率,綁定變量,讀取數據塊等等這些操作。假設高速緩沖里已經存儲了執行過的sql語句,那就直接匹配執行了,少了步驟,自然就快了,但是經過 測試會發現高速緩沖只對簡單的表起作用,多表的情況下完全沒有效果啊,例如在查詢單表的時候非常快,但是假設連接多個表,就會發現速度減了一倍不止。

最重要一點,數據庫的高速緩沖是全字符匹配的,什么意思呢,看下面三個select

--No.1
SELECT * FROM tableA;
--No.2
SELECT * FROM tableA; 
--No.3 
SELECT * FROM tableA;

  是不是覺得除了表sql都一樣?但是他看起來雖然一樣但是高速緩存是不認得,全字符匹配,索引在高速緩存里會存儲三條不同的語句,ORACLE執行的是三條不同的sql。

  1.SQL語句盡量用大寫的

  因為oracle總是先解析SQL語句,把小寫的字母轉換成大寫的再執行。

  2.使用表的別名

  當在SQL語句中連接多個表時, 盡量使用表的別名並把別名前綴於每個列上。這樣一來,就可以減少解析的時間並減少那些由列歧義引起的語法錯誤。

 

  3.選擇最有效率的表名順序(只在基於規則的優化器中有效)

     ORACLE 的解析器按照從右到左的順序處理FROM子句中的表名,FROM子句中寫在最后的表(基礎表也稱為驅動表,driving table)將被最先處理,在FROM子句中包含多個表的情況下,必須選擇記錄條數最少的表作為基礎表。如果有3個以上的表連接查詢, 那就需要選擇交叉表(intersection table)作為基礎表, 交叉表是指那個被其他表所引用的表。

例如下面的兩個語句:

--No.1  tableA 100w條記錄  tableB 1w條記錄 執行速度 十秒級
SELECT COUNT(*) FROM tableA,tableB;

--No.2  執行速度百秒級甚至更高
SELECT COUNT(*) FROM tableB,tableA; 

 

上面的結果肯定是No.2比No.1效率更高

SELSETCOUNT(1) FROM tableA a,tableB b ,tableC c WHERE a.id=b.id AND a.id=c.id;

 

上面的sql中tableA 就稱為交叉表,根據oracle對From子句從右向左的掃描方式,應該把交叉表放在最末尾,然后才是最小表,所以上面的應該這樣寫

--tableA a 交叉表 
--tabelB b 100w
--tableC c 1w
SELECT COUNT(1) FROM tableB b ,tableC c ,tableA a WHERE a.id=b.id AND a.id=c.id;

 

這種寫法對大數據量會非常有用,大家謹記,也是很常用的。

  4.Where子句后面的條件過濾有講究

  ORACLE對where子句后面的條件過濾是自下向上,從右向左掃描的,所以和From子句一樣一樣的,把過濾條件排個序,按過濾數據的大小,自然就是可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾最下面,最右邊,依次類推,例如

--No.1 不可取 性能低下
SELECT * FROM tableA a WHERE 
a.id>500
AND a.lx = '2b'
AND a.id < 'SELCET COUNT(1) FROM tableA  WHERE id=a.id '

--No.2 性能高,能過濾最多數據的條件寫在最后【謹記】
SELECT * FROM tableA a WHERE 
a.id < 'SELECT COUNT(1) FROM tableA  WHERE id=a.id '
AND a.id>500
AND a.lx = '2b

 

  5.在select的時候少用*

  多敲敲鍵盤,寫上字段名吧,因為ORACLE的查詢器會把*轉換為表的全部列名,這個會浪費時間的,所以在大表中少用。

  6.使用rowid

  常用於分頁,刪除查詢重復記錄,非常實用,給兩個例子:

--查找重復記錄
SELECT* FROM  tableA  a WHERE
 a.ROWID> (
 SELECT MIN(ROWID) FROM tableB b WHERE 
 a.column=b.column
 ) 

--刪除相同記錄
DELETE FROM  tableA  a WHERE
 a.ROWID> (
 SELECT MIN(ROWID) FROM tableB b WHERE 
 a.column=b.column
 ) 

--分頁 start=10 limit=10
--end 為 start + limit
SELECT * FROM 
(
  SELECT A.*,Rownum rn FROM 
    (SELECT * FROM tableA ORDER BY id) A
  WHERE rownum <= 20
) b WHERE rn> 10  ORDER BY id DESC 

 

/*解釋一下:

  1.查詢要排列的表 A

  2.查詢A表的Rownum 找出小於end的數據 組成表B

  3.查詢B表通過rownum找出大於start的數據 完成 簡單的說先根據end值過濾數據,然后在根據start過濾數據

是不是也感覺很實用啊......

*/

 

  

  7.減少對數據庫表的查詢

  ORACLE在內部執行了許多工作: 解析SQL語句, 估算索引的利用率, 綁定變量 , 讀數據塊等,所以少一次訪問就能提高更高的效率。

  8.使用DECODE函數來減少處理時間

  使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表. 

  使用方法:https://www.cnblogs.com/ghzjm/p/9517127.html

  9.整合簡單,無關聯的數據庫訪問

  如果你有幾個簡單的數據庫查詢語句,你可以把它們整合到一個查詢中(即使它們之間沒有關系) 

  10.刪除重復記錄

  最高效的刪除重復記錄方法 ( 因為使用了ROWID)例子:

DELETE  FROM  EMP E  WHERE  E.ROWID > (SELECT MIN(X.ROWID) 
FROM  EMP X  WHERE  X.EMP_NO = E.EMP_NO); 

  11.用TRUNCATE替代DELETE

  當刪除表中的記錄時,在通常情況下, 回滾段(rollback segments ) 用來存放可以被恢復的信息. 如果你沒有COMMIT事務,ORACLE會將數據恢復到刪除之前的狀態(准確地說是恢復到執行刪除命令之前的狀況) 而當運用TRUNCATE時, 回滾段不再存放任何可被恢復的信息.當命令運行后,數據不能被恢復.因此很少的資源被調用,執行時間也會很短. (譯者按: TRUNCATE只在刪除全表適用,TRUNCATE是DDL不是DML) 

  12.存儲過程中多用commit(謹慎使用)

  這樣程序的性能得到提高,需求也會因為COMMIT所釋放的資源而減少

  COMMIT所釋放的資源:

  a. 回滾段上用於恢復數據的信息.

  b. 被程序語句獲得的鎖

  c. redo log buffer 中的空間

  d. ORACLE為管理上述3種資源中的內部花費 

  13.不要用in,not in,用exists,not exists 來代替

--NO.1  IN的寫法  
SELECT * FROM TABLEA A WHERE 
A.ID IN 
( SELECT ID FORM TABLEB B WHERE B.ID>1)

--NO.2 exists 寫法
SELECT * FROM TABLEA A WHERE
EXISTS (
SELECT 1 FROM TABLEB B WHERE A.ID=B.ID AND B.ID>1)

  14.用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進行過濾。由此可見,要想過濾條件起到正確的作用,首先要明白這個條件應該在什么時候起作用,然后再決定放在那里 。

  15.減少對表的查詢

  在含有子查詢的SQL語句中,要特別注意減少對表的查詢.例子:

SELECT  TAB_NAME FROM TABLES
WHERE (TAB_NAME,DB_VER) = ( SELECT TAB_NAME,DB_VER FROM  TAB_COLUMNS  WHERE  VERSION = 604) 

  16.通過內部函數提高SQL效率

  復雜的SQL往往犧牲了執行效率. 能夠掌握上面的運用函數解決問題的方法在實際工作中是非常有意義的

  17.識別’低效執行’的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;

  18.用索引提高效率

  索引是表的一個概念部分,用來提高檢索數據的效率,ORACLE使用了一個復雜的自平衡B-tree結構. 通常,通過索引查詢數據比全表掃描要快. 當ORACLE找出執行查詢和Update語句的最佳路徑時, ORACLE優化器將使用索引. 同樣在聯結多個表時使用索引也可以提高效率. 另一個使用索引的好處是,它提供了主鍵(primary key)的唯一性驗

證.。那些LONG或LONG RAW數據類型, 你可以索引幾乎所有的列. 通常, 在大型表中使用索引特別有效. 當然,你也會發現, 在掃描小表時,使用索引同樣能提高效率. 雖然使用索引能得到查詢效率的提高,但是我們也必須注意到它的代價. 索引需要空間來存儲,也需要定期維護, 每當有記錄在表中增減或索引列被修改時, 索引本身也會被修改. 這意味着每條記錄的INSERT , DELETE , UPDATE將為此多付出4 , 5 次的磁盤I/O . 因為索引需要額外的存儲空間和處理,那些不必要的索引反而會使查詢反應時間變慢.。定期的重構索引是有必要的。

ALTER  INDEX <INDEXNAME> REBUILD <TABLESPACENAME>

  19.用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); 

  20.在java代碼中盡量少用連接符“+”連接字符串!

  21.通常避免在索引列上使用NOT

  我們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函數相同的影響. 當ORACLE”遇到”NOT,他就會停止使用索引轉而執行全表掃描。

  22.避免在索引列上使用計算

  WHERE子句中,如果索引列是函數的一部分.優化器將不使用索引而使用全表掃描。例如:

--低效: 
SELECTFROM  DEPT  WHERE SAL * 12 > 25000; 
--高效: 
SELECTFROM 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, 那就需要返回記錄最少的索引列寫在最前面(查看前面提到的 WHERE 條件查詢順序)

  25.避免在索引列上使用IS NULL和IS NOT NULL 

  避免在索引中使用任何可以為空的列,ORACLE將無法使用該索引.對於單列索引,如果列包含空值,索引中將不存在此記錄. 對於復合索引,如果每個列都為空,索引中同樣不存在此記錄. 如果至少有一個列不為空,則記錄存在於索引中.舉例: 如果唯一性索引建立在表的A列和B列上, 並且表中存在一條記錄的A,B值為(123,null) , ORACLE將不接受下一條具有相同A,B值(123,null)的記錄(插入). 然而如果所有的索引列都為空,ORACLE將認為整個鍵值為空而空不等於空. 因此你可以插入1000 條具有相同鍵值的記錄,當然它們都是空! 因為空值不存在於索引列中,所以WHERE子句中對索引列進行空值比較將使ORACLE停用該索引。

--低效: (索引失效) 
SELECTFROM  DEPARTMENT  WHERE  DEPT_CODE IS NOT NULL; 
--高效: (索引有效) 
SELECTFROM  DEPARTMENT  WHERE  DEPT_CODE >=0; 

  26.總是使用索引的第一個列

  如果索引是建立在多個列上, 只有在它的第一個列(leading column)被where子句引用時,優化器才會選擇使用該索引. 這也是一條簡單而重要的規則,當僅引用索引的第二個列時,優化器使用了全表掃描而忽略了索引。

  27.用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-95UNION 
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-95UNION ALL 
SELECT ACCT_NUM, BALANCE_AMT 
FROM DEBIT_TRANSACTIONS 
WHERE TRAN_DATE =31-DEC-95

  28.用WHERE替代ORDER BY

  ORDER BY 子句只在兩種嚴格的條件下使用索引.

  (a).ORDER BY中所有的列必須包含在相同的索引中並保持在索引中的排列順序.

  (b).ORDER BY中所有的列必須定義為非空.

  WHERE子句使用的索引和ORDER BY子句中所使用的索引不能並列.

  例如:

  表DEPT包含以下3列: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 

  29.避免改變索引列的類型

  當比較不同數據類型的數據時, ORACLE自動對列進行簡單的類型轉換.

--假設 EMPNO是一個數值類型的索引列.

SELECTFROM EMP  WHERE  EMPNO =123--實際上,經過ORACLE類型轉換, 語句轉化為:

SELECTFROM EMP  WHERE  EMPNO = TO_NUMBER(‘123′)

  幸運的是,類型轉換沒有發生在索引列上,索引的用途沒有被改變.

--現在,假設EMP_TYPE是一個字符類型的索引列.

SELECTFROM EMP  WHERE EMP_TYPE = 123

--這個語句被ORACLE轉換為:

SELECTFROM EMP  WHERETO_NUMBER(EMP_TYPE)=123

  因為內部發生的類型轉換, 這個索引將不會被用到! 為了避免ORACLE對你的SQL進行隱式的類型轉換, 最好把類型轉換用顯式表現出來. 注意當字符和數值比較時, ORACLE會優先轉換數值類型到字符類型 

  30.需要當心的WHERE子句

  某些SELECT 語句中的WHERE子句不使用索引. 這里有一些例子.

  在下面的例子里,

    (1) ‘!=’ 將不使用索引. 記住, 索引只能告訴你什么存在於表中, 而不能告訴你什么不存在於表中.

    (2) ‘ | |’是字符連接函數. 就象其他函數那樣, 停用了索引.

    (3) ‘+’是數學函數. 就象其他數學函數那樣, 停用了索引.

    (4)  相同的索引列不能互相比較,這將會啟用全表掃描.

  31.使用索引需要注意的兩點

  a. 如果檢索數據量超過30%的表中記錄數.使用索引將沒有顯著的效率提高。

  b. 在特定情況下, 使用索引也許會比全表掃描慢, 但這是同一個數量級上的區別. 而通常情況下,使用索引比全表掃描要快幾倍乃至幾千倍! 

  32.避免使用耗費資源的操作

  帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啟動SQL引擎

  執行耗費資源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序. 通常, 帶有UNION, MINUS , INTERSECT的SQL語句都可以用其他方式重寫. 如果你的數據庫的SORT_AREA_SIZE調配得好, 使用UNION , MINUS, INTERSECT也是可以考慮的, 畢竟它們的可讀性很強。

  33.優化GROUP BY

  提高GROUP BY 語句的效率, 可以通過將不需要的記錄在GROUP BY 之前過濾掉.下面兩個查詢返回相同結果但第二個明顯就快了許多。

  

--低效: 
SELECT JOB , AVG(SAL) 
FROM EMP 
GROUP by JOB 
HAVING JOB = ‘PRESIDENT’ 
OR JOB = ‘MANAGER’ 
--高效: 
SELECT JOB , AVG(SAL) 
FROM EMP 
WHERE JOB = ‘PRESIDENT’ 
OR JOB = ‘MANAGER’ 
GROUP by JOB 

  mysql中,索引,主鍵,唯一索引,聯合索引的區別,對數據庫的性能有什么影響。

(1)索引是一種特殊的文件(InnoDB數據表上的索引是表空間的一個組成部分),它們包含着對數據表里所有記錄的引用指針。

(2)普通索引(由關鍵字KEY或INDEX定義的索引)的唯一任務是加快對數據的訪問速度。

(3)普通索引允許被索引的數據列包含重復的值,如果能確定某個數據列只包含彼此各不相同的值,在為這個數據索引創建索引的時候就應該用關鍵字UNIQE把它定義為一個唯一所以,唯一索引可以保證數據記錄的唯一性。

(4)主鍵,一種特殊的唯一索引,在一張表中只能定義一個主鍵索引,逐漸用於唯一標識一條記錄,是用關鍵字PRIMARY KEY來創建。

(5)索引可以覆蓋多個數據列,如像INDEX索引,這就是聯合索引。

(6)索引可以極大的提高數據的查詢速度,但是會降低插入刪除更新表的速度,因為在執行這些寫操作時,還要操作索引文件。

  數據庫的鎖,行鎖、表鎖、悲觀鎖、樂觀鎖 https://blog.csdn.net/xiangwanpeng/article/details/55106732

  


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM