SQL語句編寫注意問題

　下面就某些SQL語句的where子句編寫中須要注意的問題做詳細介紹。在這些where子句中，即便某些列存在索引，可是因爲編寫了劣質的SQL，系統在運行該SQL語句時也不能使用該索引，而一樣使用全表掃描，這就形成了響應速度的極大下降。

　　1. IS NULL 與 IS NOT NULL

　　不能用null做索引，任何包含null值的列都將不會被包含在索引中。即便索引有多列這樣的狀況下，只要這些列中有一列含有null，該列就會從索引中排除。也就是說若是某列存在空值，即便對該列建索引也不會提升性能。

　　任何在where子句中使用is null或is not null的語句優化器是不容許使用索引的。

　　2. 聯接列

　　對於有聯接的列，即便最後的聯接值爲一個靜態值，優化器是不會使用索引的。咱們一塊兒來看一個例子，假定有一個職工表(employee)，對於 一個職工的姓和名分紅兩列存放(FIRST_NAME和LAST_NAME)，如今要查詢一個叫比爾.克林頓(Bill Cliton)的職工。

　　下面是一個採用聯接查詢的SQL語句，

    select * from employss where first_name||''||last_name ='Beill Cliton';

    上面這條語句徹底能夠查詢出是否有Bill Cliton這個員工，可是這裏須要注意，系統優化器對基於last_name建立的索引沒有使用。

　　當採用下面這種SQL語句的編寫，Oracle系統就能夠採用基於last_name建立的索引。

    *** where first_name ='Beill' and last_name ='Cliton';

   . 3.帶通配符(%)的like語句

　　一樣以上面的例子來看這種狀況。目前的需求是這樣的，要求在職工表中查詢名字中包含cliton的人。能夠採用以下的查詢SQL語句:

    select * from employee where last_name like '%cliton%';

    這裏因爲通配符(%)在搜尋詞首出現，因此Oracle系統不使用last_name的索引。在不少狀況下可能沒法避免這種狀況，可是必定要心中有底，通 配符如此使用會下降查詢速度。然而當通配符出如今字符串其餘位置時，優化器就能利用索引。在下面的查詢中索引獲得了使用:

    select * from employee where last_name like 'c%';

　　4. Order by語句

　　ORDER BY語句決定了Oracle如何將返回的查詢結果排序。Order by語句對要排序的列沒有什麼特別的限制，也能夠將函數加入列中(象聯接或者附加等)。任何在Order by語句的非索引項或者有計算表達式都將下降查詢速度。

　　仔細檢查order by語句以找出非索引項或者表達式，它們會下降性能。解決這個問題的辦法就是重寫order by語句以使用索引，也能夠爲所使用的列創建另一個索引，同時應絕對避免在order by子句中使用表達式。

　　5. NOT

　　咱們在查詢時常常在where子句使用一些邏輯表達式，如大於、小於、等於以及不等於等等，也可使用and(與)、or(或)以及not(非)。NOT可用來對任何邏輯運算符號取反。下面是一個NOT子句的例子:

... where not (status ='VALID')

若是要使用NOT，則應在取反的短語前面加上括號，並在短語前面加上NOT運算符。NOT運算符包含在另一個邏輯運算符中，這就是不等於(<>)運算符。換句話說，即便不在查詢where子句中顯式地加入NOT詞，NOT仍在運算符中，見下例:

... where status <>'INVALID';

對這個查詢，能夠改寫爲不使用NOT:

select * from employee where salary<3000 or salary>3000;

雖然這兩種查詢的結果同樣，可是第二種查詢方案會比第一種查詢方案更快些。第二種查詢容許Oracle對salary列使用索引，而第一種查詢則不能使用索引。

 

雖然這兩種查詢的結果同樣，可是第二種查詢方案會比第一種查詢方案更快些。第二種查詢容許Oracle對salary列使用索引，而第一種查詢則不能使用索引。

 

===============================================================================================

咱們要作到不但會寫SQL,還要作到寫出性能優良的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 by JOB 
　　HAVING JOB = ‘PRESIDENT' 
　　OR JOB = ‘MANAGER' 
　　高效: 
　　SELECT JOB , AVG(SAL) 
　　FROM EMP 
　　WHERE JOB = ‘PRESIDENT' 
　　OR JOB = ‘MANAGER' 
　　GROUP by JOB 

====================================
====================================

　　若是你正在負責一個基於SQL Server的項目，或者你剛剛接觸SQL Server，你都有可能要面臨一些數據庫性能的問題，這篇文章會爲你提供一些有用的指導（其中大多數也能夠用於其它的DBMS）。 
　　在這裏，我不打算介紹使用SQL Server的竅門，也不能提供一個包治百病的方案，我所作的是總結一些經驗----關於如何造成一個好的設計。這些經驗來自我過去幾年中經受的教訓，一直來，我看到許多一樣的設計錯誤被一次又一次的重複。 
1、瞭解你用的工具 
　　不要輕視這一點，這是我在這篇文章中講述的最關鍵的一條。也許你也看到有不少的SQL Server程序員沒有掌握所有的T-SQL命令和SQL Server提供的那些有用的工具。 
「什麼？我要浪費一個月的時間來學習那些我永遠也不會用到的SQL命令？？？」，你也許會這樣說。對的，你不須要這樣作。可是你應該用一個週末瀏覽全部的 T-SQL命令。在這裏，你的任務是瞭解，未來，當你設計一個查詢時，你會記起來：「對了，這裏有一個命令能夠徹底實現我須要的功能」，因而，到MSDN 查看這個命令的確切語法。 
2、不要使用遊標 
　　讓我再重複一遍：不要使用遊標。若是你想破壞整個系統的性能的話，它們卻是你最有效的首選辦法。大多數的初學者都使用遊標，而沒有意識到它們對性能形成的影響。它們佔用內存，還用它們那些難以想象的方式鎖定表，另外，它們簡直就像蝸牛。而最糟糕的是，它們可使你的DBA所能作的一切性能優化等於沒作。不 知你是否知道每執行一次FETCH就等於執行一次SELECT命令？這意味着若是你的遊標有10000條記錄，它將執行10000次SELECT！若是你 使用一組SELECT、UPDATE或者DELETE來完成相應的工做，那將有效率的多。 
　　初學者通常認爲使用遊標是一種比較熟悉和溫馨的編程方式，可很不幸，這會致使糟糕的性能。顯然，SQL的整體目的是你要實現什麼，而不是怎樣實現。 
我曾經用T-SQL重寫了一個基於遊標的存儲過程，那個表只有100,000條記錄，原來的存儲過程用了40分鐘才執行完畢，而新的存儲過程只用了10秒鐘。在這裏，我想你應該能夠看到一個不稱職的程序員究竟在幹了什麼！！！ 
　　咱們能夠寫一個小程序來取得和處理數據而且更新數據庫，這樣作有時會更有效。記住：對於循環，T-SQL無能爲力。 
　　我再從新提醒一下：使用遊標沒有好處。除了DBA的工做外，我歷來沒有看到過使用遊標能夠有效的完成任何工做。 
3、規範化你的數據表 
　　爲何不規範化數據庫？大概有兩個藉口：出於性能的考慮和純粹由於懶惰。至於第二點，你早晚得爲此付出代價。而關於性能的問題，你不須要優化根本就不慢的東西。我常常看到一些程序員「反規範化」數據庫，他們的理由是「原來的設計太慢了」，可結果卻經常是他們讓系統更慢了。DBMS被設計用來處理規範數據庫 的，所以，記住：按照規範化的要求設計數據庫。 
4、不要使用SELECT * 
　　這點不太容易作到，我太瞭解了，由於我本身就常常這樣幹。但是，若是在SELECT中指定你所須要的列，那將會帶來如下的好處： 
　　1 減小內存耗費和網絡的帶寬 
　　2 你能夠獲得更安全的設計 
　　3 給查詢優化器機會從索引讀取全部須要的列 
5、瞭解你將要對數據進行的操做 
　　爲你的數據庫建立一個健壯的索引，那但是功德一件。可要作到這一點簡直就是一門藝術。每當你爲一個表添加一個索引，SELECT會更快了，可INSERT 和DELETE卻大大的變慢了，由於建立了維護索引須要許多額外的工做。顯然，這裏問題的關鍵是：你要對這張表進行什麼樣的操做。這個問題不太好把握，特別是涉及DELETE和UPDATE時，由於這些語句常常在WHERE部分包含SELECT命令。 
6、不要給「性別」列建立索引 
　　首先，咱們必須瞭解索引是如何加速對錶的訪問的。你能夠將索引理解爲基於必定的標準上對錶進行劃分的一種方式。若是你給相似於「性別」這樣的列建立了一個 索引，你僅僅是將表劃分爲兩部分：男和女。你在處理一個有1,000,000條記錄的表，這樣的劃分有什麼意義？記住：維護索引是比較費時的。當你設計索 引時，請遵循這樣的規則：根據列可能包含不一樣內容的數目從多到少排列，好比：姓名+省份+性別。 
7、使用事務 
　　請使用事務，特別是當查詢比較耗時。若是系統出現問題，這樣作會救你一命的。通常有些經驗的程序員都有體會-----你常常會碰到一些不可預料的狀況會致使存儲過程崩潰。 
8、當心死鎖 
　　按照必定的次序來訪問你的表。若是你先鎖住表A，再鎖住表B，那麼在全部的存儲過程當中都要按照這個順序來鎖定它們。若是你（不經意的）某個存儲過程當中先鎖定表B，再鎖定表A，這可能就會致使一個死鎖。若是鎖定順序沒有被預先詳細的設計好，死鎖是不太容易被發現的。 
9、不要打開大的數據集 
　　一個常常被提出的問題是：我怎樣才能迅速的將100000條記錄添加到ComboBox中？這是不對的，你不能也不須要這樣作。很簡單，你的用戶要瀏覽 100000條記錄才能找到須要的記錄，他必定會詛咒你的。在這裏，你須要的是一個更好的UI，你須要爲你的用戶顯示不超過100或200條記錄。 
10、不要使用服務器端遊標 
　　與服務器端遊標比起來，客戶端遊標能夠減小服務器和網絡的系統開銷，而且還減小鎖定時間。 
11、使用參數查詢 
　　有時，我在CSDN技術論壇看到相似這樣的問題：「SELECT * FROM a WHERE a.id='A'B，由於單引號查詢發生異常，我該怎麼辦？」，而廣泛的回答是：用兩個單引號代替單引號。這是錯誤的。這樣治標不治本，由於你還會在其餘 一些字符上遇到這樣的問題，更況且這樣會致使嚴重的bug，除此之外，這樣作還會使SQL Server的緩衝系統沒法發揮應有的做用。使用參數查詢，釜底抽薪，這些問題通通不存在了。 
12、在程序編碼時使用大數據量的數據庫 
　　程序員在開發中使用的測試數據庫通常數據量都不大，可常常的是最終用戶的數據量都很大。咱們一般的作法是不對的，緣由很簡單：如今硬盤不是很貴，可爲何性能問題卻要等到已經無可挽回的時候才被注意呢？ 
十3、不要使用INSERT導入大批的數據 
　　請不要這樣作，除非那是必須的。使用UTS或者BCP，這樣你能夠一舉而兼得靈活性和速度。 
十4、注意超時問題 
　　查詢數據庫時，通常數據庫的缺省都比較小，好比15秒或者30秒。而有些查詢運行時間要比這長，特別是當數據庫的數據量不斷變大時。 
十5、不要忽略同時修改同一記錄的問題 
　　有時候，兩個用戶會同時修改同一記錄，這樣，後一個修改者修改了前一個修改者的操做，某些更新就會丟失。處理這種狀況不是很難：建立一個timestamp字段，在寫入前檢查它，若是容許，就合併修改，若是存在衝突，提示用戶。 
十6、在細節表中插入紀錄時，不要在主表執行SELECT MAX(ID) 
　　這是一個廣泛的錯誤，當兩個用戶在同一時間插入數據時，這會致使錯誤。你可使用SCOPE_IDENTITY，IDENT_CURRENT和IDENTITY。若是可能，不要使用IDENTITY，由於在有觸發器的狀況下，它會引發一些問題（詳見這裏的討論）。 
十7、避免將列設爲NULLable 
　　若是可能的話，你應該避免將列設爲NULLable。系統會爲NULLable列的每一行分配一個額外的字節，查詢時會帶來更多的系統開銷。另外，將列設爲NULLable使編碼變得複雜，由於每一次訪問這些列時都必須先進行檢查。 
　　我並非說NULLS是麻煩的根源，儘管有些人這樣認爲。我認爲若是你的業務規則中容許「空數據」，那麼，將列設爲NULLable有時會發揮很好的做用，可是，若是在相似下面的狀況中使用NULLable，那簡直就是自討苦吃。 
　　CustomerName1 
　　CustomerAddress1 
　　CustomerEmail1 
　　CustomerName2 
　　CustomerAddress2 
　　CustomerEmail3 
　　CustomerName1 
　　CustomerAddress2 
　　CustomerEmail3 
　　若是出現這種狀況，你須要規範化你的表了。 
十8、儘可能不要使用TEXT數據類型 
　　除非你使用TEXT處理一個很大的數據，不然不要使用它。由於它不易於查詢，速度慢，用的很差還會浪費大量的空間。通常的，VARCHAR能夠更好的處理你的數據。 
十9、儘可能不要使用臨時表 
　　儘可能不要使用臨時表，除非你必須這樣作。通常使用子查詢能夠代替臨時表。使用臨時表會帶來系統開銷，若是你是用COM+進行編程，它還會給你帶來很大的麻 煩，由於COM+使用數據庫鏈接池而臨時表卻自始至終都存在。SQL Server提供了一些替代方案，好比Table數據類型。 
二10、學會分析查詢 
　　SQL Server查詢分析器是你的好夥伴，經過它你能夠了解查詢和索引是如何影響性能的。 
二11、使用參照完整性 
　　定義主健、惟一性約束和外鍵，這樣作能夠節約大量的時間。

================================================================================================

【IT168 技術文檔】任何事情都有它的源頭，要解決問題，也得從源頭開始，影響ORACLE性能的源頭很是多，主要包括以下方面：數據庫的硬件配置:CPU、內存、網絡條件。

　　1. CPU:在任何機器中CPU的數據處理能力每每是衡量計算機性能的一個標誌，而且ORACLE是一個提供並行能力的數據庫系統，在CPU方面的要求就更高 了，若是運行隊列數目超過了CPU處理的數目，性能就會降低，咱們要解決的問題就是要適當增長CPU的數量了，固然咱們還能夠將須要許多資源的進程 KILL掉;

　　2. 內存:衡量機器性能的另一個指標就是內存的多少了，在ORACLE中內存和咱們在建數據庫中的交換區進行數據的交換，讀數據時，磁盤I/O必須等待物理 I/O操做完成，在出現ORACLE的內存瓶頸時，咱們第一個要考慮的是增長內存，因爲I/O的響應時間是影響ORACLE性能的主要參數，我將在這方面 進行詳細的講解

　　3. 網絡條件:NET*SQL負責數據在網絡上的來往，大量的SQL會令網絡速度變慢。好比10M的網卡和100的網卡就對NET*SQL有很是明顯的影響， 還有交換機、集線器等等網絡設備的性能對網絡的影響很明顯，建議在任何網絡中不要試圖用3個集線器來將網段互聯。

　　OS參數的設置

　　下表給出了OS的參數設置及說明，DBA能夠根據實際須要對這些參數進行設置

　　內核參數名

　　說明

　　bufpages

　　對buffer空間不按靜態分配，採用動態分配，使bufpages值隨nbuf一塊兒對buffer空間進行動態分配。

　　create_fastlinks

　　對HFS文件系統容許快速符號連接

　　dbc_max_pct

　　加大最大動態buffer空間所佔物理內存的百分比，以知足應用系統的讀寫命中率的須要。

　　dbc_min_pct

　　設置最小動態buffer空間所佔物理內存的百分比

　　desfree

　　提升開始交換操做的最低空閒內存下限，保障系統的穩定性，防止出現不可預見的系統崩潰(Crash)。

　　fs_async

　　容許進行磁盤異步操做，提升CPU和磁盤的利用率

　　lotsfree

　　提升系統解除換頁操做的空閒內存的上限值，保證應用程序有足夠的可用內存空間。

　　maxdsiz

　　針對系統數據量大的特色，加大最大數據段的大小，保證應用的須要。(32位)

　　maxdsiz_64bit

　　maximum process data segment size for 64_bit

　　Maxssiz

　　加大最大堆棧段的大小。(32_bit)

　　maxssiz_64bit

　　加大最大堆棧段的大小。(64_bit)

　　Maxtsiz

　　提升最大代碼段大小，知足應用要求

　　maxtsiz_64bit

　　原值過大，應調小

　　Minfree

　　提升中止交換操做的自由內存的上限

　　Shmem

　　容許進行內存共享，以提升內存的利用率

　　Shmmax

　　設置最大共享內存段的大小，徹底知足目前的須要

　　Timeslice

　　因爲系統的瓶頸主要反映在磁盤I/O上，所以　下降時間片的大小，一方面可避免因磁盤I/O不順暢形成CPU的等待，從而提升了CPU的綜合利用率。另外一方面減小了進程的阻塞量。

　　unlockable_mem

　　提升了不可鎖內存的大小，使可用於換頁和交換的內存空間擴大,用以知足系統對內存管理的要求。

用戶SQL質量

　　以上講的都是硬件方面的東西，在條件有限的條件下，咱們能夠調整應用程序的SQL質量:

　　1. 不要進行全表掃描(Full Table Scan):全表掃描致使大量的I/O

　　2. 儘可能建好和使用好索引:建索引也是有講究的，在建索引時，也不是索引越多越好，當一個表的索引達到4個以上時，ORACLE的性能可能仍是改善不了，由於 OLTP系統每表超過5個索引即會下降性能，並且在一個sql 中， Oracle 從不能使用超過 5個索引;當咱們用到GROUP BY和ORDER BY時,ORACLE就會自動對數據進行排序,而ORACLE在INIT.ORA中決定了sort_area_size區的大小,當排序不能在咱們給定的 排序區完成時,ORACLE就會在磁盤中進行排序,也就是咱們講的臨時表空間中排序, 過多的磁盤排序將會令 free buffer waits 的值變高,而這個區間並不僅是用於排序的,對於開發人員我提出以下忠告:

　　1)、select,update,delete 語句中的子查詢應當有規律地查找少於20%的錶行.若是一個語句查找的行數超過總行數的20%,它將不能經過使用索引得到性能上的提升.

　　2)、索引可能產生碎片,由於記錄從表中刪除時,相應也從表的索引中刪除.表釋放的空間能夠再用,而索引釋放的空間卻不能再用.頻繁進行刪除操 做的被索引的表,應當階段性地重建索引,以免在索引中形成空間碎片,影響性能.在許可的條件下,也能夠階段性地truncate表,truncate命 令刪除表中全部記錄,也刪除索引碎片.

　　3)、在使用索引時必定要按索引對應字段的順序進行引用。

　　4)、用(+)比用NOT IN更有效率。

　　下降ORACLE的競爭:

　　先講幾個ORACLE的幾個參數，這幾個參數關係到ORACLE的競爭:

　　1)、freelists 和 freelist 組:他們負責ORACLE的處理表和索引的空間管理;

　　2)、pctfree 及 pctused:該參數決定了freelists 和 freelist 組的行爲，pctfree 和pctused 參數的惟一目的就是爲了控制塊如何在 freelists 中進出

　　設置好pctfree 及 pctused對塊在freelists的移走和讀取很重要。

　　其餘參數的設置

　　1)、包括SGA區(系統全局區):系統全局區(SGA)是一個分配給Oracle 的包含一個 Oracle 實例的數據庫的控制信息內存段。

　　主要包括數據庫高速緩存(the database buffer cache)，

　　重演日誌緩存(the redo log buffer)，

　　共享池(the shared pool)，

　　數據字典緩存(the data dictionary cache)以及其它各方面的信息

　　2)、db_block_buffers(數據高速緩衝區)訪問過的數據都放在這一片內存區域，該參數越大，Oracle在內存中找到相同數據的可能性就越大，也即加快了查詢速度。

　　3)、share_pool_size (SQL共享緩衝池):該參數是庫高速緩存和數據字典的高速緩存。

　　4)、Log_buffer (重演日誌緩衝區)

　　5)、sort_area_size(排序區)

　　6)、processes (同時鏈接的進程數)

　　7)、db_block_size (數據庫塊大小):Oracle默認塊爲2KB，過小了，由於若是咱們有一個8KB的數據，則2KB塊的數據庫要讀4次盤，才能讀完，而8KB塊的數據庫 只要1次就讀完了，大大減小了I/O操做。數據庫安裝完成後，就不能再改變db_block_size的值了，只能從新創建數據庫而且建庫時，要選擇手工 安裝數據庫。

　　8)、open_links (同時打開的連接數)

　　9)、dml_locks

　　10)、open_cursors (打開光標數)

　　11)、dbwr_io_slaves (後臺寫進程數)

　

　　6. IN和EXISTS

　　有時候會將一列和一系列值相比較。最簡單的辦法就是在where子句中使用子查詢。在where子句中可使用兩種格式的子查詢。

　　第一種格式是使用IN操做符:

　　... where column in(select * from ... where ...);

　　第二種格式是使用EXIST操做符:

　　... where exists (select 'X' from ...where ...);

　　本文引用自http://www.cnblogs.com/ziyiFly/archive/2008/12/24/1361380.html。