1、使用系統性能監視器監視當前SQL的工作性能（控制面板-->管理工具-->性能）可以查看SQL對磁碟、內存的總體佔用
2、使用SQL 性能監視器（SQL Profiler）可以查看SQL 的執行事件，讀寫次數，起始和結束事件等等，可以保存死鎖圖形。
Ⅱ 如何進行SQL性能優化
SQL Server資料庫查詢速度慢的原因有很多，常見的有以下幾種：
1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是資料庫設計的缺陷)
2、I/O吞吐量小，形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網路速度慢
6、查詢出的數據量過大（可以採用多次查詢，其他的方法降低數據量）
7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設計的缺陷)
8、sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優化
●可以通過以下方法來優化查詢 :
1、把數據、日誌、索引放到不同的I/O設備上，增加讀取速度，以前可以將Tempdb應放在RAID0上，SQL2000不在支持。數據量（尺寸）越大，提高I/O越重要。
2、縱向、橫向分割表，減少表的尺寸(sp_spaceuse)
3、升級硬體
4、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當（最好是使用默認值0）。索引應該盡量小，使用位元組數小的列建索引好（參照索引的創建）,不要對有限的幾個值的欄位建單一索引如性別欄位。
5、提高網速。
6、擴大伺服器的內存,Windows 2000和SQL server 2000能支持4-8G的內存。
配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置。運行 Microsoft SQL Server? 2000時，可考慮將虛擬內存大小設置為計算機中安裝的物理內存的1.5倍。如果另外安裝了全文檢索功能，並打算運行Microsoft搜索服務以便執行全文索引和查詢，可考慮：將虛擬內存大小配置為至少是計算機中安裝的物理內存的3倍。將SQL Server max server memory伺服器配置選項配置為物理內存的1.5倍（虛擬內存大小設置的一半）。
7、增加伺服器CPU個數;但是必須 明白並行處理串列處理更需要資源例如內存。使用並行還是串列程是MSSQL自動評估選擇的。單個任務分解成多個任務，就可以在處理器上運行。例如耽擱查詢 的排序、連接、掃描和GROUP BY字句同時執行，SQL SERVER根據系統的負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢最適合並行處理。但是更新操作UPDATE,INSERT， DELETE還不能並行處理。
8、如果是使用like進行查詢的話，簡單的使用index是不行的，但是全文索引，耗空間。 like ''a%'' 使用索引 like ''%a'' 不使用索引用 like ''%a%'' 查詢時，查詢耗時和欄位值總長度成正比,所以不能用CHAR類型，而是VARCHAR。對於欄位的值很長的建全文索引。
9、DB Server 和APPLication Server 分離；OLTP和OLAP分離
10、分布式分區視圖可用於實現資料庫伺服器聯合體。
聯合體是一組分開管理的伺服器，但它們相互協作分擔系統的處理負荷。這種通過分區數據形成資料庫伺服器聯合體的機制能夠擴大一組伺服器，以支持大型的多層 Web 站點的處理需要。有關更多信息，參見設計聯合資料庫伺服器。（參照SQL幫助文件''分區視圖''）
a、在實現分區視圖之前，必須先水平分區表
b、 在創建成員表後，在每個成員伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣，引用分布式分區視圖名的查詢可以在任何一個成員伺服器上 運行。系統操作如同每個成員伺服器上都有一個原始表的復本一樣，但其實每個伺服器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數據和日誌 DBCC SHRINKDB,DBCC SHRINKFILE. 設置自動收縮日誌.對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。
在T-sql的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計劃的過程是這樣的：
1、 查詢語句的詞法、語法檢查
2、 將語句提交給DBMS的查詢優化器
3、 優化器做代數優化和存取路徑的優化
4、 由預編譯模塊生成查詢規劃
5、 然後在合適的時間提交給系統處理執行
6、 最後將執行結果返回給用戶。
其次，看一下SQL SERVER的數據存放的結構：一個頁面的大小為8K(8060)位元組，8個頁面為一個盤區，按照B樹存放。
Ⅲ 如何測試sql語句性能，提高執行效率，sql2008
一段SQL代碼寫好以後，可以通過查看SQL的執行計劃，初步預測該SQL在運行時的性能好壞，尤其是在發現某個SQL語句的效率較差時，我們可以通過查看執行計劃，分析出該SQL代碼的問題所在。 1、 打開熟悉的查看工具：PL/SQL Developer。 在PL/SQL Developer中寫好一段SQL代碼後，按F5，PL/SQL Developer會自動打開執行計劃窗口，顯示該SQL的執行計劃。 2、 查看總COST，獲得資源耗費的總體印象 一般而言，執行計劃第一行所對應的COST(即成本耗費)值，反應了運行這段SQL的總體估計成本，單看這個總成本沒有實際意義，但可以拿它與相同邏輯不同執行計劃的SQL的總體COST進行比較，通常COST低的執行計劃要好一些。 3、 按照從左至右，從上至下的方法，了解執行計劃的執行步驟 執行計劃按照層次逐步縮進，從左至右看，縮進最多的那一步，最先執行，如果縮進量相同，則按照從上而下的方法判斷執行順序，可粗略認為上面的步驟優先執行。每一個執行步驟都有對應的COST,可從單步COST的高低，以及單步的估計結果集（對應ROWS/基數），來分析表的訪問方式，連接順序以及連接方式是否合理。 4、 分析表的訪問方式 表的訪問方式主要是兩種：全表掃描（TABLE ACCESS FULL）和索引掃描(INDEX SCAN)，如果表上存在選擇性很好的索引，卻走了全表掃描，而且是大表的全表掃描，就說明表的訪問方式可能存在問題；若大表上沒有合適的索引而走了全表掃描，就需要分析能否建立索引，或者是否能選擇更合適的表連接方式和連接順序以提高效率。 5、 分析表的連接方式和連接順序 表的連接順序：就是以哪張表作為驅動表來連接其他表的先後訪問順序。 表的連接方式：簡單來講，就是兩個表獲得滿足條件的數據時的連接過程。主要有三種表連接方式，嵌套循環（NESTED LOOPS）、哈希連接（HASH JOIN）和排序-合並連接（SORT MERGE JOIN）。我們常見得是嵌套循環和哈希連接。 嵌套循環：最適用也是最簡單的連接方式。類似於用兩層循環處理兩個游標，外層游標稱作驅動表，Oracle檢索驅動表的數據，一條一條的代入內層游標，查找滿足WHERE條件的所有數據，因此內層游標表中可用索引的選擇性越好，嵌套循環連接的性能就越高。 哈希連接：先將驅動表的數據按照條件欄位以散列的方式放入內存，然後在內存中匹配滿足條件的行。哈希連接需要有合適的內存，而且必須在CBO優化模式下，連接兩表的WHERE條件有等號的情況下才可以使用。哈希連接在表的數據量較大，表中沒有合適的索引可用時比嵌套循環的效率要高。
Ⅳ SQL資料庫性能和資料庫調優
連接數量有三種方法查看 1.通過系統的逗性能地來查看： 開始->管理工具->性能（或者是運行裡面輸入 mmc）然後通過 添加計數器添加 SQL 的常用統計 然後在下面列出的項目裡面選擇用戶連接就可以時時查詢到sql server資料庫連接數了。 不過此方法的話需要有訪問那台計算機的許可權，就是要通過windows賬戶登陸進去才可以添加此計數器。 2.通過系統表來查詢： SELECT * FROM [Master].[dbo].[SYSPROCESSES] WHERE [DBID] IN ( SELECT [DBID] FROM [Master].[dbo].[SYSDATABASES] WHERE NAME='databaseName' ) databaseName 是需要查看的資料庫，然後查詢出來的行數，就是當前的sql server資料庫連接數。不過裡面還有一些別的狀態可以做參考用。 3.通過系統過程來查詢： SP_WHO 'loginName' loginName 是當然登陸Sql的用戶名，一般程序裡面都會使用一個username來登陸SQL這樣通過這個用戶名就能查看到此用戶名登陸之後佔用的連接了。 如果不寫loginName，那麼返回的就是所有的sql server資料庫連接。 至於如何改善資料庫性能，就是屬於資料庫調優方面的工作了，通常有以下幾種調優方法： 1 查看資料庫中造成資料庫訪問變慢的語句，通常是執行數量較多，執行速度慢的語句，對這些語句進行執行計劃分析，並重寫語句來優化，最常見的就是not in語句使用外連接語句代替； 2 根據語句中查詢訪問條件中的謂詞，創建對應的索引，以提高查詢的執行效率； 3 在數據存儲上優化，將數據文件根據某個頻繁訪問屬性的屬性值進行水平分片，提高對應表的訪問效率（oracle支持，sql server2000沒有此功能） 4 重新設計業務邏輯結構，避免執行代價高的查詢語句 5 伺服器和資料庫軟體的能力終究還是有限的，無論如何優化當達到一定的訪問數量是還是會超出負載，此時就需要考慮可擴展規模的分布式並行數據存儲架構了。
Ⅳ SQL查詢語句性能優化建議
1對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
3.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
4.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查詢也將導致全表掃描：
select id from t where name like '«c%'
若要提高效率，可以考慮全文檢索。
7.如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時;它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
8.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改為:
select id from t where num=100*2
9.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
select id from t where datediff(day,createdate,'2005-11-30')=0--『2005-11-30』生成的id
應改為:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
11.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致
12.不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0
這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
create table #t(...)
13.很多時候用 exists 代替 in 是一個好的選擇：
select num from a where num in(selectnum from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
14.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。
15.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
16.應盡可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那麼需要考慮是否應將該索引建為 clustered 索引。
17.盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。
19.任何地方都不要使用 select * from t ，用具體的欄位列表代替「*」，不要返回用不到的任何欄位。
20.盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限(只有主鍵索引)。
21.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
22.臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
23.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度;如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。
24.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
25.盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那麼就應該考慮改寫。
26.使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
27.與臨時表一樣，游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括「合計」的常式通常要比使用游標執行的速度快。如果開發時間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
28.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。
29.盡量避免大事務操作，提高系統並發能力。
30.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
Ⅵ sql語句性能如何優化
如何加快查詢速度?
1、升級硬體
2、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。
3、擴大伺服器的內存
4、增加伺服器CPU個數
5、對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能
6、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
7、查詢時不要返回不需要的行、列
8、用select
top
100
/
10
Percent
來限制用戶返回的行數或者SET
ROWCOUNT來限制操作的行
9、在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，減少判斷的次數
10、一般在GROUP
BY
個HAVING字句之前就能剔除多餘的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：
select的Where字句選擇所有合適的行，Group
By用來分組個統計行，Having字句用來剔除多餘的分組。這樣Group
By
個Having的開銷小，查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group
BY的目的不包括計算，只是分組，那麼用Distinct更快
11、一次更新多條記錄比分多次更新每次一條快,就是說批處理好
Ⅶ 如何做SQL Server性能測試
1、打開sql server studio management2、打開"工具"-"sql server profiler"3、點擊連接4、點擊運行5、可以看到捕捉到的一些野肢訪問資料庫的事件，其中有讀寫，點用cpu，持續時間等信息可以參考6、點擊某個事件，可以查看具頌知世體執行了什麼sql腳本，進一步分析相關邏猛此輯
Ⅷ SQL多表連接查詢的性能與標準的問題
性能優化比較復雜，除了數據量，還要看索引一類的其他指標攔歷虧
如果你用的是ORACLE，而且是比較新的版本，
那麼只要你不特殊提示優化器，哪個在前哪個在後無所謂，優化器會自己做選擇
如果你想看一個SQL資料庫到底是怎麼簡神執行的，需要去看執行計劃，有些時候，優爛兆化器會自動改寫你的SQL以實現更優的效率
Ⅸ 高手詳解SQL性能優化十條經驗
查詢的模糊匹配
盡量避免在一個復雜查詢裡面使用 LIKE %parm % —— 紅色標識位置的百分號會導致相關列的索引無法使用 最好不要用
解決辦法:
其實只需要對該腳本略做改進 查詢速度便會提高近百倍 改進方法如下
a 修改前台程序——把查詢條件的供應商名稱一欄由原來的文本輸入改為下拉列表 用戶模糊輸入供拿禪旁應商名稱時 直接在前台就幫忙定位到具體的供應商 這樣在調用後台程序時 這列就可以直接用等於來關聯了
b 直接修改後台——根據輸入條件 先查出符合條件的供應商 並把相關記錄保存在一個臨時表裡頭 然後再用臨時表去做復雜關聯
索引問題
在做性能跟蹤分析過程中 經常發現有不少後台程序的性能問題是因為缺少合適索引造成的 有些表甚至一個索引都沒有 這種情況往往都是因為在設計表時 沒去定義索引 而開發初期 由於表記錄很少 索引創建與否 可能對性能沒啥影響 開發人員因此也未多加重視 然一旦程序發布到生產環境 隨著時間的推移 表記錄越來越多
這時缺少索引 對性能的影響便會越來越大了
這個問題需要資料庫設計人員和開發人員共消橡同關注
法則 不要在建立的索引的數據列上進行下列操作:
◆避免對索引欄位進行計算操作◆避免在索引欄位上使用not <> !=◆避免在索引列上使用IS NULL和IS NOT NULL ◆避免在索引列上出現數據類型轉換◆避免在索引欄位上使用函數 ◆避免建立索引的列中使用空值
復雜操作
部分UPDATE SELECT 語句 寫得很復雜（經常嵌套多級子查詢）——可以考慮適當拆成幾步 先生成一些臨時數據表 再進行關聯操作
update
同一個表的修改在一個過程里出現好幾十次 如
update table set col = where col = ;update table set col = where col =象這類腳本其實可以很簡單就整合在一個UPDATE語句來完成（前些時候在協助xxx項目做性能問題分析時就發現存在這種情況）
在可以使用UNION ALL的語句里 使用了UNION
UNION 因為會將各查詢子集的記錄做比較 故比起UNION ALL 通常速度都會慢上許多 一般來說 如果使用UNION ALL能滿足要求的話 務必使用UNION ALL 還有一種情況大家可能會忽略掉 就是雖然要求幾個子集的並集需要過濾掉重復記錄 但由於腳本的特殊性 不可能存在重復記錄 這時便應該使用UNION ALL 如xx模塊的某個查詢程序就曾經存在這種情況 見 由於語句的特殊性 在這個腳本中幾個子集的記錄絕對不可能重復 故可以改用UNION ALL）
在WHERE 語句中 盡量避免對索引欄位進行計算操作
這個常識相信絕大部分開發人員都應該知道 但仍有不少人這么使用 我想其中一個最主要的原因可能是為了編寫寫簡單而損害了性能 那就不可取了
月份在對XX系統做性能分析時發現 有大量的後台程序存在類似用法 如
where trunc(create_date)=trunc(:date )雖然已對create_date 欄位建了索引 但由於加了TRUNC 使得索引無法用上 此處正確的寫法應該是
where create_date>=trunc(:date ) and create_date或者是
where create_date beeen trunc(:date ) and trunc(:date )+ /( * * )注意 因beeen 的范圍是個閉區間（greater than or equal to low value and less than or equal to high value ） 故嚴格意義上應該再減去一個趨於 的小數 這里暫且設置成減去 秒（ /( * * )） 如果不要求這么精確的話 可以襲凳略掉這步
對Where 語句的法則
避免在WHERE子句中使用in not in or 或者having
可以使用 exist 和not exist代替 in和not in
可以使用表鏈接代替 exist Having可以用where代替 如果無法代替可以分兩步處理
例子
SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN (SELECT CUSTOMER_NAME FROM CUSTOMER) 優化 SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist (SELECT CUSTOMER_NAME FROM CUSTOMER)不要以字元格式聲明數字 要以數字格式聲明字元值 （日期同樣）否則會使索引無效 產生全表掃描 例子使用 SELECT emp ename emp job FROM emp WHERE emp empno = ;不要使用 SELECT emp ename emp job FROM emp WHERE emp empno =
對Select語句的法則
在應用程序 包和過程中限制使用select * from table這種方式 看下面例子
使用SELECT empno ename category FROM emp WHERE empno = 而不要使用SELECT * FROM emp WHERE empno =
排序
避免使用耗費資源的操作 帶有DISTINCT UNION MINUS INTERSECT ORDER BY的SQL語句會啟動SQL引擎 執行 耗費資源的排序(SORT)功能 DISTINCT需要一次排序操作 而其他的至少需要執行兩次排序
臨時表
lishixin/Article/program/SQL/201311/16379
Ⅹ 怎麼提高這個很簡單的SQL的性能
在SQL查詢中，為了提高查詢的效率，我們常常採取一些措施對查詢語句進行SQL性能優化。本文我們總結了一些優化措施，接下來我們就一一介紹。
1.查詢的模糊匹配
盡量避免在一個復雜查詢裡面使用 LIKE '%parm1%'—— 紅色標識位置的百分號會導致相關列的索引無法使用，最好不要用。
解決辦法:
其實只需要對該腳本略做改進，查詢速度便會提高近百倍。改進方法如下：
a、修改前台程序——把查詢條件的供應商名稱一欄由原來的文本輸入改為下拉列表，用戶模糊輸入供應商名稱時，直接在前台就幫忙定位到具體的供應商，這樣在調用後台程序時，這列就可以直接用等於來關聯了。
b、直接修改後台——根據輸入條件，先查出符合條件的供應商，並把相關記錄保存在一個臨時表裡頭，然後再用臨時表去做復雜關聯。
2.索引問題
在做性能跟蹤分析過程中，經常發現有不少後台程序的性能問題是因為缺少合適索引造成的，有些表甚至一個索引都沒有。這種情況往往都是因為在設計表時，沒去定義索引，而開發初期，由於表記錄很少，索引創建與否，可能對性能沒啥影響，開發人員因此也未多加重視。然一旦程序發布到生產環境，隨著時間的推移，表記錄越來越多。這時缺少索引，對性能的影響便會越來越大了。
法則：不要在建立的索引的數據列上進行下列操作:
避免對索引欄位進行計算操作
避免在索引欄位上使用not，<>，!=
避免在索引列上使用IS NULL和IS NOT NULL
避免在索引列上出現數據類型轉換
避免在索引欄位上使用函數
避免建立索引的列中使用空值
3.復雜操作
部分UPDATE、SELECT 語句 寫得很復雜（經常嵌套多級子查詢）——可以考慮適當拆成幾步，先生成一些臨時數據表，再進行關聯操作。
4.update
同一個表的修改在一個過程里出現好幾十次，如：
update table1 set col1=... where col2=...; update table1 set col1=... where col2=... ...
這類腳本其實可以很簡單就整合在一個UPDATE語句來完成（前些時候在協助xxx項目做性能問題分析時就發現存在這種情況）
5.在可以使用UNION ALL的語句里，使用了UNION
UNION 因為會將各查詢子集的記錄做比較，故比起UNION ALL ，通常速度都會慢上許多。一般來說，如果使用UNION ALL能滿足要求的話，務必使用UNION ALL。還有一種情況大家可能會忽略掉，就是雖然要求幾個子集的並集需要過濾掉重復記錄，但由於腳本的特殊性，不可能存在重復記錄，這時便應該使用 UNION ALL，如xx模塊的某個查詢程序就曾經存在這種情況，見，由於語句的特殊性，在這個腳本中幾個子集的記錄絕對不可能重復，故可以改用UNION ALL）。
6.在WHERE 語句中，盡量避免對索引欄位進行計算操作
這個常識相信絕大部分開發人員都應該知道，但仍有不少人這么使用，我想其中一個最主要的原因可能是為了編寫寫簡單而損害了性能，那就不可取了。9月份在對XX系統做性能分析時發現，有大量的後台程序存在類似用法，如：where trunc(create_date)=trunc(:date1)，雖然已對create_date 欄位建了索引，但由於加了TRUNC，使得索引無法用上。此處正確的寫法應該是where create_date>=trunc(:date1) and create_date< pre=""><>或者是where create_date between trunc(:date1) and trunc(:date1)+1-1/(24*60*60)。
注意：因between 的范圍是個閉區間（greater than or equal to low value and less than or equal to high value.），故嚴格意義上應該再減去一個趨於0的小數，這里暫且設置成減去1秒（1/(24*60*60)），如果不要求這么精確的話，可以略掉這步。
7.對Where 語句的法則
7.1 避免在WHERE子句中使用in，not in，or 或者having。
可以使用 exist 和not exist代替in和not in。
可以使用表鏈接代替 exist。Having可以用where代替，如果無法代替可以分兩步處理。
例子
SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN (SELECT CUSTOMER_NAME FROM CUSTOMER)
優化
SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist (SELECT CUSTOMER_NAME FROM CUSTOMER)
7.2 不要以字元格式聲明數字，要以數字格式聲明字元值。（日期同樣）否則會使索引無效，產生全表掃描。
例子使用：
SELECT emp.ename, emp.job FROM emp WHERE emp.empno = 7369;
--不要使用：
SELECT emp.ename, emp.job FROM emp WHERE emp.empno = '7369'
8.對Select語句的法則
在應用程序、包和過程中限制使用select * from table這種方式。看下面例子
--使用
SELECT empno,ename,category FROM emp WHERE empno = '7369'
--而不要使用
SELECT * FROM emp WHERE empno = '7369'
9. 排序
避免使用耗費資源的操作，帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啟動SQL引擎 執行，耗費資源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序。
10.臨時表
慎重使用臨時表可以極大的提高系統性能。
關於SQL性能優化的知識就介紹到這里了，希望本次的介紹能夠帶給您一些收獲，謝謝！