MS SQL Server查詢優(yōu)化方法

查詢速度慢的原因很多，常見(jiàn)如下幾種

1、沒(méi)有索引或者沒(méi)有用到索引(這是查詢慢最常見(jiàn)的問(wèn)題，是程序設(shè)計(jì)的缺陷)
2、I/O吞吐量小，形成了瓶頸效應(yīng)。
3、沒(méi)有創(chuàng)建計(jì)算列導(dǎo)致查詢不優(yōu)化。
4、內(nèi)存不足
5、網(wǎng)絡(luò)速度慢
6、查詢出的數(shù)據(jù)量過(guò)大（可以采用多次查詢，其他的方法降低數(shù)據(jù)量）
7、鎖或者死鎖(這也是查詢慢最常見(jiàn)的問(wèn)題，是程序設(shè)計(jì)的缺陷)
8、sp_lock,sp_who,活動(dòng)的用戶查看,原因是讀寫(xiě)競(jìng)爭(zhēng)資源。
9、返回了不必要的行和列
10、查詢語(yǔ)句不好，沒(méi)有優(yōu)化

可以通過(guò)如下方法來(lái)優(yōu)化查詢

1、把數(shù)據(jù)、日志、索引放到不同的I/O設(shè)備上，增加讀取速度，以前可以將Tempdb應(yīng)放在RAID0上，SQL2000不在支持。數(shù)據(jù)量（尺寸）越大，提高I/O越重要.
2、縱向、橫向分割表，減少表的尺寸(sp_spaceuse)
3、升級(jí)硬件
4、根據(jù)查詢條件,建立索引,優(yōu)化索引、優(yōu)化訪問(wèn)方式，限制結(jié)果集的數(shù)據(jù)量。注意填充因子要適當(dāng)（最好是使用默認(rèn)值0）。索引應(yīng)該盡量小，使用字節(jié)數(shù)小的列建索引好（參照索引的創(chuàng)建）,不要對(duì)有限的幾個(gè)值的字段建單一索引如性別字段
5、提高網(wǎng)速;
6、擴(kuò)大服務(wù)器的內(nèi)存,Windows 2000和SQL server 2000能支持4-8G的內(nèi)存。配置虛擬內(nèi)存：虛擬內(nèi)存大小應(yīng)基于計(jì)算機(jī)上并發(fā)運(yùn)行的服務(wù)進(jìn)行配置。運(yùn)行 Microsoft SQL Server? 2000 時(shí)，可考慮將虛擬內(nèi)存大小設(shè)置為計(jì)算機(jī)中安裝的物理內(nèi)存的 1.5 倍。如果另外安裝了全文檢索功能，并打算運(yùn)行 Microsoft 搜索服務(wù)以便執(zhí)行全文索引和查詢，可考慮：將虛擬內(nèi)存大小配置為至少是計(jì)算機(jī)中安裝的物理內(nèi)存的 3 倍。將 SQL Server max server memory 服務(wù)器配置選項(xiàng)配置為物理內(nèi)存的 1.5 倍（虛擬內(nèi)存大小設(shè)置的一半）。
7、增加服務(wù)器CPU個(gè)數(shù);但是必須明白并行處理串行處理更需要資源例如內(nèi)存。使用并行還是串行程是MsSQL自動(dòng)評(píng)估選擇的。單個(gè)任務(wù)分解成多個(gè)任務(wù)，就可以在處理器上運(yùn)行。例如耽擱查詢的排序、連接、掃描和GROUP BY字句同時(shí)執(zhí)行，SQL SERVER根據(jù)系統(tǒng)的負(fù)載情況決定最優(yōu)的并行等級(jí)，復(fù)雜的需要消耗大量的CPU的查詢最適合并行處理。但是更新操作UPDATE,INSERT， DELETE還不能并行處理。
8、如果是使用like進(jìn)行查詢的話，簡(jiǎn)單的使用index是不行的，但是全文索引，耗空間。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時(shí)，查詢耗時(shí)和字段值總長(zhǎng)度成正比,所以不能用CHAR類型，而是VARCHAR。對(duì)于字段的值很長(zhǎng)的建全文索引。
9、DB Server 和APPLication Server 分離；OLTP和OLAP分離
10、分布式分區(qū)視圖可用于實(shí)現(xiàn)數(shù)據(jù)庫(kù)服務(wù)器聯(lián)合體。聯(lián)合體是一組分開(kāi)管理的服務(wù)器，但它們相互協(xié)作分擔(dān)系統(tǒng)的處理負(fù)荷。這種通過(guò)分區(qū)數(shù)據(jù)形成數(shù)據(jù)庫(kù)服務(wù)器聯(lián)合體的機(jī)制能夠擴(kuò)大一組服務(wù)器，以支持大型的多層 Web 站點(diǎn)的處理需要。有關(guān)更多信息，參見(jiàn)設(shè)計(jì)聯(lián)合數(shù)據(jù)庫(kù)服務(wù)器。（參照SQL幫助文件'分區(qū)視圖'）

a、在實(shí)現(xiàn)分區(qū)視圖之前，必須先水平分區(qū)表
b、在創(chuàng)建成員表后，在每個(gè)成員服務(wù)器上定義一個(gè)分布式分區(qū)視圖，并且每個(gè)視圖具有相同的名稱。這樣，引用分布式分區(qū)視圖名的查詢可以在任何一個(gè)成員服務(wù)器上運(yùn)行。系統(tǒng)操作如同每個(gè)成員服務(wù)器上都有一個(gè)原始表的復(fù)本一樣，但其實(shí)每個(gè)服務(wù)器上只有一個(gè)成員表和一個(gè)分布式分區(qū)視圖。數(shù)據(jù)的位置對(duì)應(yīng)用程序是透明的。

11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數(shù)據(jù)和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 設(shè)置自動(dòng)收縮日志.對(duì)于大的數(shù)據(jù)庫(kù)不要設(shè)置數(shù)據(jù)庫(kù)自動(dòng)增長(zhǎng)，它會(huì)降低服務(wù)器的性能。 在T-sql的寫(xiě)法上有很大的講究，下面列出常見(jiàn)的要點(diǎn)：首先，DBMS處理查詢計(jì)劃的過(guò)程是這樣的：

1、 查詢語(yǔ)句的詞法、語(yǔ)法檢查
2、 將語(yǔ)句提交給DBMS的查詢優(yōu)化器
3、 優(yōu)化器做代數(shù)優(yōu)化和存取路徑的優(yōu)化
4、 由預(yù)編譯模塊生成查詢規(guī)劃
5、 然后在合適的時(shí)間提交給系統(tǒng)處理執(zhí)行
6、 最后將執(zhí)行結(jié)果返回給用戶其次，看一下SQL SERVER的數(shù)據(jù)存放的結(jié)構(gòu)：一個(gè)頁(yè)面的大小為8K(8060)字節(jié)，8個(gè)頁(yè)面為一個(gè)盤(pán)區(qū)，按照B樹(shù)存放。

12、Commit和rollback的區(qū)別 Rollback:回滾所有的事物。 Commit:提交當(dāng)前的事物. 沒(méi)有必要在動(dòng)態(tài)SQL里寫(xiě)事物，如果要寫(xiě)請(qǐng)寫(xiě)在外面如： begin tran exec(@s) commit trans 或者將動(dòng)態(tài)SQL 寫(xiě)成函數(shù)或者存儲(chǔ)過(guò)程。

13、在查詢Select語(yǔ)句中用Where字句限制返回的行數(shù),避免表掃描,如果返回不必要的數(shù)據(jù)，浪費(fèi)了服務(wù)器的I/O資源，加重了網(wǎng)絡(luò)的負(fù)擔(dān)降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯(lián)接訪問(wèn)表,后果嚴(yán)重。

14、SQL的注釋申明對(duì)執(zhí)行沒(méi)有任何影響

15、盡可能不使用光標(biāo)，它占用大量的資源。如果需要row-by-row地執(zhí)行，盡量采用非光標(biāo)技術(shù),如：在客戶端循環(huán)，用臨時(shí)表，Table變量，用子查詢，用Case語(yǔ)句等等。游標(biāo)可以按照它所支持的提取選項(xiàng)進(jìn)行分類： 只進(jìn) 必須按照從第一行到最后一行的順序提取行。FETCH NEXT 是唯一允許的提取操作,也是默認(rèn)方式?？蓾L動(dòng)性 可以在游標(biāo)中任何地方隨機(jī)提取任意行。游標(biāo)的技術(shù)在SQL2000下變得功能很強(qiáng)大，他的目的是支持循環(huán)。

有四個(gè)并發(fā)選項(xiàng)

READ_ONLY：不允許通過(guò)游標(biāo)定位更新(Update)，且在組成結(jié)果集的行中沒(méi)有鎖。

OPTIMISTIC WITH valueS:樂(lè)觀并發(fā)控制是事務(wù)控制理論的一個(gè)標(biāo)準(zhǔn)部分。樂(lè)觀并發(fā)控制用于這樣的情形，即在打開(kāi)游標(biāo)及更新行的間隔中，只有很小的機(jī)會(huì)讓第二個(gè)用戶更新某一行。當(dāng)某個(gè)游標(biāo)以此選項(xiàng)打開(kāi)時(shí)，沒(méi)有鎖控制其中的行，這將有助于最大化其處理能力。如果用戶試圖修改某一行，則此行的當(dāng)前值會(huì)與最后一次提取此行時(shí)獲取的值進(jìn)行比較。如果任何值發(fā)生改變，則服務(wù)器就會(huì)知道其他人已更新了此行，并會(huì)返回一個(gè)錯(cuò)誤。如果值是一樣的，服務(wù)器就執(zhí)行修改。 選擇這個(gè)并發(fā)選項(xiàng)OPTIMISTIC WITH ROW VERSIONING:此樂(lè)觀并發(fā)控制選項(xiàng)基于行版本控制。使用行版本控制，其中的表必須具有某種版本標(biāo)識(shí)符，服務(wù)器可用它來(lái)確定該行在讀入游標(biāo)后是否有所更改。
在 SQL Server 中，這個(gè)性能由 timestamp 數(shù)據(jù)類型提供，它是一個(gè)二進(jìn)制數(shù)字，表示數(shù)據(jù)庫(kù)中更改的相對(duì)順序。每個(gè)數(shù)據(jù)庫(kù)都有一個(gè)全局當(dāng)前時(shí)間戳值：@@DBTS。每次以任何方式更改帶有 timestamp 列的行時(shí)，SQL Server 先在時(shí)間戳列中存儲(chǔ)當(dāng)前的 @@DBTS 值，然后增加 @@DBTS 的值。如果某 個(gè)表具有 timestamp 列，則時(shí)間戳?xí)挥浀叫屑?jí)。服務(wù)器就可以比較某行的當(dāng)前時(shí)間戳值和上次提取時(shí)所存儲(chǔ)的時(shí)間戳值，從而確定該行是否已更新。服務(wù)器不必比較所有列的值，只需比較 timestamp 列即可。如果應(yīng)用程序?qū)](méi)有 timestamp 列的表要求基于行版本控制的樂(lè)觀并發(fā)，則游標(biāo)默認(rèn)為基于數(shù)值的樂(lè)觀并發(fā)控制。
SCROLL LOCKS 這個(gè)選項(xiàng)實(shí)現(xiàn)悲觀并發(fā)控制。在悲觀并發(fā)控制中，在把數(shù)據(jù)庫(kù)的行讀入游標(biāo)結(jié)果集時(shí)，應(yīng)用程序?qū)⒃噲D鎖定數(shù)據(jù)庫(kù)行。在使用服務(wù)器游標(biāo)時(shí)，將行讀入游標(biāo)時(shí)會(huì)在其上放置一個(gè)更新鎖。如果在事務(wù)內(nèi)打開(kāi)游標(biāo)，則該事務(wù)更新鎖將一直保持到事務(wù)被提交或回滾；當(dāng)提取下一行時(shí)，將除去游標(biāo)鎖。如果在事務(wù)外打開(kāi)游標(biāo)，則提取下一行時(shí)，鎖就被丟棄。因此，每當(dāng)用戶需要完全的悲觀并發(fā)控制時(shí)，游標(biāo)都應(yīng)在事務(wù)內(nèi)打開(kāi)。更新鎖將阻止任何其它任務(wù)獲取更新鎖或排它鎖，從而阻止其它任務(wù)更新該行。
然而，更新鎖并不阻止共享鎖，所以它不會(huì)阻止其它任務(wù)讀取行，除非第二個(gè)任務(wù)也在要求帶更新鎖的讀取。滾動(dòng)鎖根據(jù)在游標(biāo)定義的 SELECT 語(yǔ)句中指定的鎖提示，這些游標(biāo)并發(fā)選項(xiàng)可以生成滾動(dòng)鎖。滾動(dòng)鎖在提取時(shí)在每行上獲取，并保持到下次提取或者游標(biāo)關(guān)閉，以先發(fā)生者為準(zhǔn)。下次提取時(shí)，服務(wù)器為新提取中的行獲取滾動(dòng)鎖，并釋放上次提取中行的滾動(dòng)鎖。滾動(dòng)鎖獨(dú)立于事務(wù)鎖，并可以保持到一個(gè)提交或回滾操作之后。如果提交時(shí)關(guān)閉游標(biāo)的選項(xiàng)為關(guān)，則 COMMIT 語(yǔ)句并不關(guān)閉任何打開(kāi)的游標(biāo)，而且滾動(dòng)鎖被保留到提交之后，以維護(hù)對(duì)所提取數(shù)據(jù)的隔離。所獲取滾動(dòng)鎖的類型取決于游標(biāo)并發(fā)選項(xiàng)和游標(biāo) SELECT 語(yǔ)句中的鎖提示。
鎖提示 只讀 樂(lè)觀數(shù)值 樂(lè)觀行版本控制 鎖定無(wú)提示 未鎖定 未鎖定 未鎖定 更新 NOLOCK 未鎖定 未鎖定 未鎖定 未鎖定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 錯(cuò)誤 更新 更新 更新 TABLOCKX 錯(cuò)誤 未鎖定 未鎖定 更新其它 未鎖定 未鎖定 未鎖定 更新 *指定 NOLOCK 提示將使指定了該提示的表在游標(biāo)內(nèi)是只讀的。

16、用Profiler來(lái)跟蹤查詢，得到查詢所需的時(shí)間，找出SQL的問(wèn)題所在;用索引優(yōu)化器優(yōu)化索引

17、注意UNion和UNion all 的區(qū)別。UNION all好

18、注意使用DISTINCT，在沒(méi)有必要時(shí)不要用，它同UNION一樣會(huì)使查詢變慢。重復(fù)的記錄在查詢里是沒(méi)有問(wèn)題的

19、查詢時(shí)不要返回不需要的行、列

20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT來(lái)限制查詢消耗的資源。當(dāng)評(píng)估查詢消耗的資源超出限制時(shí)，服務(wù)器自動(dòng)取消查詢,在查詢之前就扼殺掉。 SET LOCKTIME設(shè)置鎖的時(shí)間
21、用select top 100 / 10 Percent 來(lái)限制用戶返回的行數(shù)或者SET ROWCOUNT來(lái)限制操作的行

22、在SQL2000以前，一般不要用如下的字句: "IS NULL", " <> ", "!=", "!> ", "! <", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因?yàn)樗麄儾蛔咚饕潜頀呙?。也不要在WHere字句中的列名加函數(shù)，如Convert，substring等,如果必須用函數(shù)的時(shí)候，創(chuàng)建計(jì)算列再創(chuàng)建索引來(lái)替代.還可以變通寫(xiě)法：WHERE SUBSTRING(firstname,1,1) = 'm'改為WHERE firstname like 'm%'（索引掃描），一定要將函數(shù)和列名分開(kāi)。并且索引不能建得太多和太大。NOT IN會(huì)多次掃描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 來(lái)替代，特別是左連接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，現(xiàn)在2000的優(yōu)化器能夠處理了。相同的是IS NULL，“NOT", "NOT EXISTS", "NOT IN"能優(yōu)化她，而” <> ”等還是不能優(yōu)化，用不到索引。

23、使用Query Analyzer，查看SQL語(yǔ)句的查詢計(jì)劃和評(píng)估分析是否是優(yōu)化的SQL。一般的20%的代碼占據(jù)了80%的資源，我們優(yōu)化的重點(diǎn)是這些慢的地方。

24、如果使用了IN或者OR等時(shí)發(fā)現(xiàn)查詢沒(méi)有走索引，使用顯示申明指定索引： SELECT * FROM PersonMember (INDEX = IX_Title) WHERE processid IN (‘男'，‘女')

25、將需要查詢的結(jié)果預(yù)先計(jì)算好放在表中，查詢的時(shí)候再SELECT。這在SQL7.0以前是最重要的手段。例如醫(yī)院的住院費(fèi)計(jì)算。

26、MIN() 和 MAX()能使用到合適的索引

27、數(shù)據(jù)庫(kù)有一個(gè)原則是代碼離數(shù)據(jù)越近越好，所以優(yōu)先選擇Default,依次為Rules,Triggers, Constraint（約束如外健主健CheckUNIQUE……,數(shù)據(jù)類型的最大長(zhǎng)度等等都是約束）,Procedure.這樣不僅維護(hù)工作小，編寫(xiě)程序質(zhì)量高，并且執(zhí)行的速度快。

28、如果要插入大的二進(jìn)制值到Image列，使用存儲(chǔ)過(guò)程，千萬(wàn)不要用內(nèi)嵌INsert來(lái)插入(不知JAVA是否)。因?yàn)檫@樣應(yīng)用程序首先將二進(jìn)制值轉(zhuǎn)換成字符串（尺寸是它的兩倍），服務(wù)器受到字符后又將他轉(zhuǎn)換成二進(jìn)制值.存儲(chǔ)過(guò)程就沒(méi)有這些動(dòng)作: 方法：Create procedure p_insert as insert into table(Fimage) values (@image), 在前臺(tái)調(diào)用這個(gè)存儲(chǔ)過(guò)程傳入二進(jìn)制參數(shù)，這樣處理速度明顯改善。

29、Between在某些時(shí)候比IN速度更快,Between能夠更快地根據(jù)索引找到范圍。用查詢優(yōu)化器可見(jiàn)到差別。 select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一樣的。由于in會(huì)在比較多次，所以有時(shí)會(huì)慢些。

30、在必要是對(duì)全局或者局部臨時(shí)表創(chuàng)建索引，有時(shí)能夠提高速度，但不是一定會(huì)這樣，因?yàn)樗饕埠馁M(fèi)大量的資源。他的創(chuàng)建同是實(shí)際表一樣。

31、不要建沒(méi)有作用的事物例如產(chǎn)生報(bào)表時(shí)，浪費(fèi)資源。只有在必要使用事物時(shí)使用它。

32、用OR的字句可以分解成多個(gè)查詢，并且通過(guò)UNION 連接多個(gè)查詢。他們的速度只同是否使用索引有關(guān),如果查詢需要用到聯(lián)合索引，用UNION all執(zhí)行的效率更高.多個(gè)OR的字句沒(méi)有用到索引，改寫(xiě)成UNION的形式再試圖與索引匹配。一個(gè)關(guān)鍵的問(wèn)題是否用到索引。

33、盡量少用視圖，它的效率低。對(duì)視圖操作比直接對(duì)表操作慢,可以用stored procedure來(lái)代替她。特別的是不要用視圖嵌套,嵌套視圖增加了尋找原始資料的難度。我們看視圖的本質(zhì)：它是存放在服務(wù)器上的被優(yōu)化好了的已經(jīng)產(chǎn)生了查詢規(guī)劃的SQL。對(duì)單個(gè)表檢索數(shù)據(jù)時(shí)，不要使用指向多個(gè)表的視圖，直接從表檢索或者僅僅包含這個(gè)表的視圖上讀，否則增加了不必要的開(kāi)銷,查詢受到干擾.為了加快視圖的查詢，MsSQL增加了視圖索引的功能。

34、沒(méi)有必要時(shí)不要用DISTINCT和ORDER BY，這些動(dòng)作可以改在客戶端執(zhí)行。它們?cè)黾恿祟~外的開(kāi)銷。這同UNION 和UNION ALL一樣的道理。 SELECT top 20 ad.companyname,comid,position,ad.referenceid,worklocation, convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescription FROM jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345','JCNAD00333138','JCNAD00303570', 'JCNAD00303569','JCNAD00303568','JCNAD00306698','JCNAD00231935','JCNAD00231933','JCNAD00254567', 'JCNAD00254585','JCNAD00254608','JCNAD00254607','JCNAD00258524','JCNAD00332133','JCNAD00268618', 'JCNAD00279196','JCNAD00268613') order by postdate desc

35、在IN后面值的列表中，將出現(xiàn)最頻繁的值放在最前面，出現(xiàn)得最少的放在最后面，減少判斷的次數(shù)

36、當(dāng)用SELECT INTO時(shí)，它會(huì)鎖住系統(tǒng)表(sysobjects，sysindexes等等)，阻塞其他的連接的存取。創(chuàng)建臨時(shí)表時(shí)用顯示申明語(yǔ)句，而不是 select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where name = 'XYZ' --commit 在另一個(gè)連接中SELECT * from sysobjects可以看到 SELECT INTO 會(huì)鎖住系統(tǒng)表，Create table 也會(huì)鎖系統(tǒng)表(不管是臨時(shí)表還是系統(tǒng)表)。所以千萬(wàn)不要在事物內(nèi)使用它?。。∵@樣的話如果是經(jīng)常要用的臨時(shí)表請(qǐng)使用實(shí)表，或者臨時(shí)表變量。

37、一般在GROUP BY 個(gè)HAVING字句之前就能剔除多余的行，所以盡量不要用它們來(lái)做剔除行的工作。他們的執(zhí)行順序應(yīng)該如下最優(yōu)：select 的Where字句選擇所有合適的行，Group By用來(lái)分組個(gè)統(tǒng)計(jì)行，Having字句用來(lái)剔除多余的分組。這樣Group By 個(gè)Having的開(kāi)銷小，查詢快.對(duì)于大的數(shù)據(jù)行進(jìn)行分組和Having十分消耗資源。如果Group BY的目的不包括計(jì)算，只是分組，那么用Distinct更快

38、一次更新多條記錄比分多次更新每次一條快,就是說(shuō)批處理好

39、少用臨時(shí)表，盡量用結(jié)果集和Table類性的變量來(lái)代替它,Table 類型的變量比臨時(shí)表好

40、在SQL2000下，計(jì)算字段是可以索引的，需要滿足的條件如下：

a、計(jì)算字段的表達(dá)是確定的
b、不能用在TEXT,Ntext，Image數(shù)據(jù)類型
c、必須配制如下選項(xiàng) ANSI_NULLS = ON, ANSI_PADDINGS = ON, …….

41、盡量將數(shù)據(jù)的處理工作放在服務(wù)器上，減少網(wǎng)絡(luò)的開(kāi)銷，如使用存儲(chǔ)過(guò)程。存儲(chǔ)過(guò)程是編譯好、優(yōu)化過(guò)、并且被組織到一個(gè)執(zhí)行規(guī)劃里、且存儲(chǔ)在數(shù)據(jù)庫(kù)中的 SQL語(yǔ)句，是控制流語(yǔ)言的集合，速度當(dāng)然快。反復(fù)執(zhí)行的動(dòng)態(tài)SQL,可以使用臨時(shí)存儲(chǔ)過(guò)程，該過(guò)程（臨時(shí)表）被放在Tempdb中。以前由于SQL SERVER對(duì)復(fù)雜的數(shù)學(xué)計(jì)算不支持，所以不得不將這個(gè)工作放在其他的層上而增加網(wǎng)絡(luò)的開(kāi)銷。SQL2000支持UDFs,現(xiàn)在支持復(fù)雜的數(shù)學(xué)計(jì)算，函數(shù)的返回值不要太大，這樣的開(kāi)銷很大。用戶自定義函數(shù)象光標(biāo)一樣執(zhí)行的消耗大量的資源，如果返回大的結(jié)果采用存儲(chǔ)過(guò)程

42、不要在一句話里再三的使用相同的函數(shù)，浪費(fèi)資源,將結(jié)果放在變量里再調(diào)用更快

43、SELECT COUNT(*)的效率教低，盡量變通他的寫(xiě)法，而EXISTS快.同時(shí)請(qǐng)注意區(qū)別： select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的。

44、當(dāng)服務(wù)器的內(nèi)存夠多時(shí)，配制線程數(shù)量 = 最大連接數(shù)+5，這樣能發(fā)揮最大的效率；否則使用 配制線程數(shù)量 <最大連接數(shù)啟用SQL SERVER的線程池來(lái)解決,如果還是數(shù)量 = 最大連接數(shù)+5，嚴(yán)重的損害服務(wù)器的性能。

45、按照一定的次序來(lái)訪問(wèn)你的表。如果你先鎖住表A，再鎖住表B，那么在所有的存儲(chǔ)過(guò)程中都要按照這個(gè)順序來(lái)鎖定它們。如果你（不經(jīng)意的）某個(gè)存儲(chǔ)過(guò)程中先鎖定表B，再鎖定表A，這可能就會(huì)導(dǎo)致一個(gè)死鎖。如果鎖定順序沒(méi)有被預(yù)先詳細(xì)的設(shè)計(jì)好，死鎖很難被發(fā)現(xiàn)

46、通過(guò)SQL Server Performance Monitor監(jiān)視相應(yīng)硬件的負(fù)載 Memory: Page Faults / sec計(jì)數(shù)器如果該值偶爾走高，表明當(dāng)時(shí)有線程競(jìng)爭(zhēng)內(nèi)存。如果持續(xù)很高，則內(nèi)存可能是瓶頸。 Process:

1、% DPC Time 指在范例間隔期間處理器用在緩延程序調(diào)用(DPC)接收和提供服務(wù)的百分比。(DPC 正在運(yùn)行的為比標(biāo)準(zhǔn)間隔優(yōu)先權(quán)低的間隔)。 由于 DPC 是以特權(quán)模式執(zhí)行的，DPC 時(shí)間的百分比為特權(quán)時(shí)間 百分比的一部分。這些時(shí)間單獨(dú)計(jì)算并且不屬于間隔計(jì)算總數(shù)的一部 分。這個(gè)總數(shù)顯示了作為實(shí)例時(shí)間百分比的平均忙時(shí)。
2、%Processor Time計(jì)數(shù)器　如果該參數(shù)值持續(xù)超過(guò)95%，表明瓶頸是CPU?？梢钥紤]增加一個(gè)處理器或換一個(gè)更快的處理器。
3、% Privileged Time 指非閑置處理器時(shí)間用于特權(quán)模式的百分比。(特權(quán)模式是為操作系統(tǒng)組件和操縱硬件驅(qū)動(dòng)程序而設(shè)計(jì)的一種處理模式。它允許直接訪問(wèn)硬件和所有內(nèi)存。另一種模式為用戶模式，它是一種為應(yīng)用程序、環(huán)境分系統(tǒng)和整數(shù)分系統(tǒng)設(shè)計(jì)的一種有限處理模式。操作系統(tǒng)將應(yīng)用程序線程轉(zhuǎn)換成特權(quán)模式以訪問(wèn)操作系統(tǒng)服務(wù))。 特權(quán)時(shí)間的 % 包括為間斷和 DPC 提供服務(wù)的時(shí)間。特權(quán)時(shí)間比率高可能是由于失敗設(shè)備產(chǎn)生的大數(shù)量的間隔而引起的。這個(gè)計(jì)數(shù)器將平均忙時(shí)作為樣本時(shí)間的一部分顯示。
4、% User Time表示耗費(fèi)CPU的數(shù)據(jù)庫(kù)操作，如排序，執(zhí)行aggregate functions等。如果該值很高，可考慮增加索引，盡量使用簡(jiǎn)單的表聯(lián)接，水平分割大表格等方法來(lái)降低該值。 Physical Disk: Curretn Disk Queue Length計(jì)數(shù)器該值應(yīng)不超過(guò)磁盤(pán)數(shù)的1.5~2倍。要提高性能，可增加磁盤(pán)。 SQLServer:Cache Hit Ratio計(jì)數(shù)器該值越高越好。如果持續(xù)低于80%，應(yīng)考慮增加內(nèi)存。 注意該參數(shù)值是從SQL Server啟動(dòng)后，就一直累加記數(shù)，所以運(yùn)行經(jīng)過(guò)一段時(shí)間后，該值將不能反映系統(tǒng)當(dāng)前值。
47、分析select emp_name form employee where salary > 3000 在此語(yǔ)句中若salary是Float類型的，則優(yōu)化器對(duì)其進(jìn)行優(yōu)化為Convert(float,3000)，因?yàn)?000是個(gè)整數(shù)，我們應(yīng)在編程時(shí)使用3000.0而不要等運(yùn)行時(shí)讓DBMS進(jìn)行轉(zhuǎn)化。同樣字符和整型數(shù)據(jù)的轉(zhuǎn)換。

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

我們要做到不但會(huì)寫(xiě)SQL,還要做到寫(xiě)出性能優(yōu)良的SQL,以下為筆者學(xué)習(xí)、摘錄、并匯總部分資料與大家分享！
（1） 選擇最有效率的表名順序(只在基于規(guī)則的優(yōu)化器中有效)：
ORACLE 的解析器按照從右到左的順序處理FROM子句中的表名，F(xiàn)ROM子句中寫(xiě)在最后的表(基礎(chǔ)表 driving table)將被最先處理，在FROM子句中包含多個(gè)表的情況下,你必須選擇記錄條數(shù)最少的表作為基礎(chǔ)表。如果有3個(gè)以上的表連接查詢, 那就需要選擇交叉表(intersection table)作為基礎(chǔ)表, 交叉表是指那個(gè)被其他表所引用的表.
（2） WHERE子句中的連接順序．：
ORACLE采用自下而上的順序解析WHERE子句,根據(jù)這個(gè)原理,表之間的連接必須寫(xiě)在其他WHERE條件之前, 那些可以過(guò)濾掉最大數(shù)量記錄的條件必須寫(xiě)在WHERE子句的末尾.
（3） SELECT子句中避免使用 ‘ * ‘：
ORACLE在解析的過(guò)程中, 會(huì)將'*' 依次轉(zhuǎn)換成所有的列名, 這個(gè)工作是通過(guò)查詢數(shù)據(jù)字典完成的, 這意味著將耗費(fèi)更多的時(shí)間
（4） 減少訪問(wèn)數(shù)據(jù)庫(kù)的次數(shù)：
ORACLE在內(nèi)部執(zhí)行了許多工作: 解析SQL語(yǔ)句, 估算索引的利用率, 綁定變量 , 讀數(shù)據(jù)塊等；
（5） 在SQL*Plus , SQL*Forms和Pro*C中重新設(shè)置ARRAYSIZE參數(shù), 可以增加每次數(shù)據(jù)庫(kù)訪問(wèn)的檢索數(shù)據(jù)量 ,建議值為200
（6） 使用DECODE函數(shù)來(lái)減少處理時(shí)間：
使用DECODE函數(shù)可以避免重復(fù)掃描相同記錄或重復(fù)連接相同的表.
（7） 整合簡(jiǎn)單,無(wú)關(guān)聯(lián)的數(shù)據(jù)庫(kù)訪問(wèn)：
如果你有幾個(gè)簡(jiǎn)單的數(shù)據(jù)庫(kù)查詢語(yǔ)句,你可以把它們整合到一個(gè)查詢中(即使它們之間沒(méi)有關(guān)系)
（8） 刪除重復(fù)記錄：
最高效的刪除重復(fù)記錄方法 ( 因?yàn)槭褂昧薘OWID)例子：
DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)
FROM EMP X WHERE X.EMP_NO = E.EMP_NO);
（9） 用TRUNCATE替代DELETE：
當(dāng)刪除表中的記錄時(shí),在通常情況下, 回滾段(rollback segments ) 用來(lái)存放可以被恢復(fù)的信息. 如果你沒(méi)有COMMIT事務(wù),ORACLE會(huì)將數(shù)據(jù)恢復(fù)到刪除之前的狀態(tài)(準(zhǔn)確地說(shuō)是恢復(fù)到執(zhí)行刪除命令之前的狀況) 而當(dāng)運(yùn)用TRUNCATE時(shí), 回滾段不再存放任何可被恢復(fù)的信息.當(dāng)命令運(yùn)行后,數(shù)據(jù)不能被恢復(fù).因此很少的資源被調(diào)用,執(zhí)行時(shí)間也會(huì)很短. (譯者按: TRUNCATE只在刪除全表適用,TRUNCATE是DDL不是DML)
（10） 盡量多使用COMMIT：
只要有可能,在程序中盡量多使用COMMIT, 這樣程序的性能得到提高,需求也會(huì)因?yàn)镃OMMIT所釋放的資源而減少:
COMMIT所釋放的資源:
a. 回滾段上用于恢復(fù)數(shù)據(jù)的信息.
b. 被程序語(yǔ)句獲得的鎖
c. redo log buffer 中的空間
d. ORACLE為管理上述3種資源中的內(nèi)部花費(fèi)
（11） 用Where子句替換HAVING子句：
避免使用HAVING子句, HAVING 只會(huì)在檢索出所有記錄之后才對(duì)結(jié)果集進(jìn)行過(guò)濾. 這個(gè)處理需要排序,總計(jì)等操作. 如果能通過(guò)WHERE子句限制記錄的數(shù)目,那就能減少這方面的開(kāi)銷. (非oracle中)on、where、having這三個(gè)都可以加條件的子句中，on是最先執(zhí)行，where次之，having最后，因?yàn)閛n是先把不符合條件的記錄過(guò)濾后才進(jìn)行統(tǒng)計(jì)，它就可以減少中間運(yùn)算要處理的數(shù)據(jù)，按理說(shuō)應(yīng)該速度是最快的，where也應(yīng)該比having快點(diǎn)的，因?yàn)樗^(guò)濾數(shù)據(jù)后才進(jìn)行sum，在兩個(gè)表聯(lián)接時(shí)才用on的，所以在一個(gè)表的時(shí)候，就剩下where跟having比較了。在這單表查詢統(tǒng)計(jì)的情況下，如果要過(guò)濾的條件沒(méi)有涉及到要計(jì)算字段，那它們的結(jié)果是一樣的，只是where可以使用rushmore技術(shù)，而having就不能，在速度上后者要慢如果要涉及到計(jì)算的字段，就表示在沒(méi)計(jì)算之前，這個(gè)字段的值是不確定的，根據(jù)上篇寫(xiě)的工作流程，where的作用時(shí)間是在計(jì)算之前就完成的，而having就是在計(jì)算后才起作用的，所以在這種情況下，兩者的結(jié)果會(huì)不同。在多表聯(lián)接查詢時(shí)，on比where更早起作用。系統(tǒng)首先根據(jù)各個(gè)表之間的聯(lián)接條件，把多個(gè)表合成一個(gè)臨時(shí)表后，再由where進(jìn)行過(guò)濾，然后再計(jì)算，計(jì)算完后再由having進(jìn)行過(guò)濾。由此可見(jiàn)，要想過(guò)濾條件起到正確的作用，首先要明白這個(gè)條件應(yīng)該在什么時(shí)候起作用，然后再?zèng)Q定放在那里
（12） 減少對(duì)表的查詢：
在含有子查詢的SQL語(yǔ)句中,要特別注意減少對(duì)表的查詢.例子：
SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECT
TAB_NAME,DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)
（13） 通過(guò)內(nèi)部函數(shù)提高SQL效率.：
復(fù)雜的SQL往往犧牲了執(zhí)行效率. 能夠掌握上面的運(yùn)用函數(shù)解決問(wèn)題的方法在實(shí)際工作中是非常有意義的
（14） 使用表的別名(Alias)：
當(dāng)在SQL語(yǔ)句中連接多個(gè)表時(shí), 請(qǐng)使用表的別名并把別名前綴于每個(gè)Column上.這樣一來(lái),就可以減少解析的時(shí)間并減少那些由Column歧義引起的語(yǔ)法錯(cuò)誤.
（15） 用EXISTS替代IN、用NOT EXISTS替代NOT IN：
在許多基于基礎(chǔ)表的查詢中,為了滿足一個(gè)條件,往往需要對(duì)另一個(gè)表進(jìn)行聯(lián)接.在這種情況下, 使用EXISTS(或NOT EXISTS)通常將提高查詢的效率. 在子查詢中,NOT IN子句將執(zhí)行一個(gè)內(nèi)部的排序和合并. 無(wú)論在哪種情況下,NOT IN都是最低效的 (因?yàn)樗鼘?duì)子查詢中的表執(zhí)行了一個(gè)全表遍歷). 為了避免使用NOT IN ,我們可以把它改寫(xiě)成外連接(Outer Joins)或NOT EXISTS.
例子：
（高效）SELECT * FROM EMP (基礎(chǔ)表) WHERE EMPNO > 0 AND EXISTS (SELECT ‘X' FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = ‘MELB')
(低效)SELECT * FROM EMP (基礎(chǔ)表) WHERE EMPNO > 0 AND DEPTNO IN(SELECT DEPTNO FROM DEPT WHERE LOC = ‘MELB')
（16） 識(shí)別'低效執(zhí)行'的SQL語(yǔ)句：
雖然目前各種關(guān)于SQL優(yōu)化的圖形化工具層出不窮,但是寫(xiě)出自己的SQL工具來(lái)解決問(wèn)題始終是一個(gè)最好的方法：
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） 用索引提高效率：
索引是表的一個(gè)概念部分,用來(lái)提高檢索數(shù)據(jù)的效率，ORACLE使用了一個(gè)復(fù)雜的自平衡B-tree結(jié)構(gòu). 通常,通過(guò)索引查詢數(shù)據(jù)比全表掃描要快. 當(dāng)ORACLE找出執(zhí)行查詢和Update語(yǔ)句的最佳路徑時(shí), ORACLE優(yōu)化器將使用索引. 同樣在聯(lián)結(jié)多個(gè)表時(shí)使用索引也可以提高效率. 另一個(gè)使用索引的好處是,它提供了主鍵(primary key)的唯一性驗(yàn)證.。那些LONG或LONG RAW數(shù)據(jù)類型, 你可以索引幾乎所有的列. 通常, 在大型表中使用索引特別有效. 當(dāng)然,你也會(huì)發(fā)現(xiàn), 在掃描小表時(shí),使用索引同樣能提高效率. 雖然使用索引能得到查詢效率的提高,但是我們也必須注意到它的代價(jià). 索引需要空間來(lái)存儲(chǔ),也需要定期維護(hù), 每當(dāng)有記錄在表中增減或索引列被修改時(shí), 索引本身也會(huì)被修改. 這意味著每條記錄的INSERT , DELETE , UPDATE將為此多付出4 , 5 次的磁盤(pán)I/O . 因?yàn)樗饕枰~外的存儲(chǔ)空間和處理,那些不必要的索引反而會(huì)使查詢反應(yīng)時(shí)間變慢.。定期的重構(gòu)索引是有必要的.：
ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>
18） 用EXISTS替換DISTINCT：
當(dāng)提交一個(gè)包含一對(duì)多表信息(比如部門表和雇員表)的查詢時(shí),避免在SELECT子句中使用DISTINCT. 一般可以考慮用EXIST替換, EXISTS 使查詢更為迅速,因?yàn)镽DBMS核心模塊將在子查詢的條件一旦滿足后,立刻返回結(jié)果. 例子：
(低效):
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語(yǔ)句用大寫(xiě)的；因?yàn)閛racle總是先解析sql語(yǔ)句，把小寫(xiě)的字母轉(zhuǎn)換成大寫(xiě)的再執(zhí)行
（20） 在java代碼中盡量少用連接符“＋”連接字符串！
（21） 避免在索引列上使用NOT 通常，　
我們要避免在索引列上使用NOT, NOT會(huì)產(chǎn)生在和在索引列上使用函數(shù)相同的影響. 當(dāng)ORACLE”遇到”NOT,他就會(huì)停止使用索引轉(zhuǎn)而執(zhí)行全表掃描.
（22） 避免在索引列上使用計(jì)算．
WHERE子句中，如果索引列是函數(shù)的一部分．優(yōu)化器將不使用索引而使用全表掃描．
舉例:
低效：
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
兩者的區(qū)別在于, 前者DBMS將直接跳到第一個(gè)DEPT等于4的記錄而后者將首先定位到DEPTNO=3的記錄并且向前掃描到第一個(gè)DEPT大于3的記錄.
（24） 用UNION替換OR (適用于索引列)
通常情況下, 用UNION替換WHERE子句中的OR將會(huì)起到較好的效果. 對(duì)索引列使用OR將造成全表掃描. 注意, 以上規(guī)則只針對(duì)多個(gè)索引列有效. 如果有column沒(méi)有被索引, 查詢效率可能會(huì)因?yàn)槟銢](méi)有選擇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”
如果你堅(jiān)持要用OR, 那就需要返回記錄最少的索引列寫(xiě)在最前面.
（25） 用IN來(lái)替換OR
這是一條簡(jiǎn)單易記的規(guī)則，但是實(shí)際的執(zhí)行效果還須檢驗(yàn)，在ORACLE8i下，兩者的執(zhí)行路徑似乎是相同的．　
低效:
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將無(wú)法使用該索引．對(duì)于單列索引，如果列包含空值，索引中將不存在此記錄. 對(duì)于復(fù)合索引，如果每個(gè)列都為空，索引中同樣不存在此記錄.　如果至少有一個(gè)列不為空，則記錄存在于索引中．舉例: 如果唯一性索引建立在表的A列和B列上, 并且表中存在一條記錄的A,B值為(123,null) , ORACLE將不接受下一條具有相同A,B值（123,null）的記錄(插入). 然而如果所有的索引列都為空，ORACLE將認(rèn)為整個(gè)鍵值為空而空不等于空. 因此你可以插入1000 條具有相同鍵值的記錄,當(dāng)然它們都是空! 因?yàn)榭罩挡淮嬖谟谒饕兄?所以WHERE子句中對(duì)索引列進(jìn)行空值比較將使ORACLE停用該索引.
低效: (索引失效)
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;
高效: (索引有效)
SELECT … FROM DEPARTMENT WHERE DEPT_CODE >=0;
（27） 總是使用索引的第一個(gè)列：
如果索引是建立在多個(gè)列上, 只有在它的第一個(gè)列(leading column)被where子句引用時(shí),優(yōu)化器才會(huì)選擇使用該索引. 這也是一條簡(jiǎn)單而重要的規(guī)則，當(dāng)僅引用索引的第二個(gè)列時(shí),優(yōu)化器使用了全表掃描而忽略了索引
28） 用UNION-ALL 替換UNION ( 如果有可能的話)：
當(dāng)SQL 語(yǔ)句需要UNION兩個(gè)查詢結(jié)果集合時(shí),這兩個(gè)結(jié)果集合會(huì)以UNION-ALL的方式被合并, 然后在輸出最終結(jié)果前進(jìn)行排序. 如果用UNION ALL替代UNION, 這樣排序就不是必要了. 效率就會(huì)因此得到提高. 需要注意的是，UNION ALL 將重復(fù)輸出兩個(gè)結(jié)果集合中相同記錄. 因此各位還是要從業(yè)務(wù)需求分析使用UNION ALL的可行性. UNION 將對(duì)結(jié)果集合排序,這個(gè)操作會(huì)使用到SORT_AREA_SIZE這塊內(nèi)存. 對(duì)于這塊內(nèi)存的優(yōu)化也是相當(dāng)重要的. 下面的SQL可以用來(lái)查詢排序的消耗量
低效：
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 子句只在兩種嚴(yán)格的條件下使用索引.
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） 避免改變索引列的類型.:
當(dāng)比較不同數(shù)據(jù)類型的數(shù)據(jù)時(shí), ORACLE自動(dòng)對(duì)列進(jìn)行簡(jiǎn)單的類型轉(zhuǎn)換.
假設(shè) EMPNO是一個(gè)數(shù)值類型的索引列.
SELECT … FROM EMP WHERE EMPNO = ‘123'
實(shí)際上,經(jīng)過(guò)ORACLE類型轉(zhuǎn)換, 語(yǔ)句轉(zhuǎn)化為:
SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(‘123')
幸運(yùn)的是,類型轉(zhuǎn)換沒(méi)有發(fā)生在索引列上,索引的用途沒(méi)有被改變.
現(xiàn)在,假設(shè)EMP_TYPE是一個(gè)字符類型的索引列.
SELECT … FROM EMP WHERE EMP_TYPE = 123
這個(gè)語(yǔ)句被ORACLE轉(zhuǎn)換為:
SELECT … FROM EMP WHERETO_NUMBER(EMP_TYPE)=123
因?yàn)閮?nèi)部發(fā)生的類型轉(zhuǎn)換, 這個(gè)索引將不會(huì)被用到! 為了避免ORACLE對(duì)你的SQL進(jìn)行隱式的類型轉(zhuǎn)換, 最好把類型轉(zhuǎn)換用顯式表現(xiàn)出來(lái). 注意當(dāng)字符和數(shù)值比較時(shí), ORACLE會(huì)優(yōu)先轉(zhuǎn)換數(shù)值類型到字符類型
（31） 需要當(dāng)心的WHERE子句:
某些SELECT 語(yǔ)句中的WHERE子句不使用索引. 這里有一些例子.
在下面的例子里, (1)‘!=' 將不使用索引. 記住, 索引只能告訴你什么存在于表中, 而不能告訴你什么不存在于表中. (2) ‘||'是字符連接函數(shù). 就象其他函數(shù)那樣, 停用了索引. (3) ‘+'是數(shù)學(xué)函數(shù). 就象其他數(shù)學(xué)函數(shù)那樣, 停用了索引. (4)相同的索引列不能互相比較,這將會(huì)啟用全表掃描.
（32） a. 如果檢索數(shù)據(jù)量超過(guò)30%的表中記錄數(shù).使用索引將沒(méi)有顯著的效率提高.
b. 在特定情況下, 使用索引也許會(huì)比全表掃描慢, 但這是同一個(gè)數(shù)量級(jí)上的區(qū)別. 而通常情況下,使用索引比全表掃描要塊幾倍乃至幾千倍!
（33） 避免使用耗費(fèi)資源的操作:
帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語(yǔ)句會(huì)啟動(dòng)SQL引擎
執(zhí)行耗費(fèi)資源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要執(zhí)行兩次排序. 通常, 帶有UNION, MINUS , INTERSECT的SQL語(yǔ)句都可以用其他方式重寫(xiě). 如果你的數(shù)據(jù)庫(kù)的SORT_AREA_SIZE調(diào)配得好, 使用UNION , MINUS, INTERSECT也是可以考慮的, 畢竟它們的可讀性很強(qiáng)
（34） 優(yōu)化GROUP BY:
提高GROUP BY 語(yǔ)句的效率, 可以通過(guò)將不需要的記錄在GROUP BY 之前過(guò)濾掉.下面兩個(gè)查詢返回相同結(jié)果但第二個(gè)明顯就快了許多.
低效:

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

優(yōu)化SQL查詢：如何寫(xiě)出高性能SQL語(yǔ)句

1、 首先要搞明白什么叫執(zhí)行計(jì)劃？

執(zhí)行計(jì)劃是數(shù)據(jù)庫(kù)根據(jù)SQL語(yǔ)句和相關(guān)表的統(tǒng)計(jì)信息作出的一個(gè)查詢方案，這個(gè)方案是由查詢優(yōu)化器自動(dòng)分析產(chǎn)生的，比如一條SQL語(yǔ)句如果用來(lái)從一個(gè) 10萬(wàn)條記錄的表中查1條記錄，那查詢優(yōu)化器會(huì)選擇“索引查找”方式，如果該表進(jìn)行了歸檔，當(dāng)前只剩下5000條記錄了，那查詢優(yōu)化器就會(huì)改變方案，采用 “全表掃描”方式。

可見(jiàn)，執(zhí)行計(jì)劃并不是固定的，它是“個(gè)性化的”。產(chǎn)生一個(gè)正確的“執(zhí)行計(jì)劃”有兩點(diǎn)很重要：

(1) SQL語(yǔ)句是否清晰地告訴查詢優(yōu)化器它想干什么？
(2) 查詢優(yōu)化器得到的數(shù)據(jù)庫(kù)統(tǒng)計(jì)信息是否是最新的、正確的？

2、 統(tǒng)一SQL語(yǔ)句的寫(xiě)法

對(duì)于以下兩句SQL語(yǔ)句，程序員認(rèn)為是相同的，數(shù)據(jù)庫(kù)查詢優(yōu)化器認(rèn)為是不同的。

其實(shí)就是大小寫(xiě)不同，查詢分析器就認(rèn)為是兩句不同的SQL語(yǔ)句，必須進(jìn)行兩次解析。生成2個(gè)執(zhí)行計(jì)劃。所以作為程序員，應(yīng)該保證相同的查詢語(yǔ)句在任何地方都一致，多一個(gè)空格都不行！

3、 不要把SQL語(yǔ)句寫(xiě)得太復(fù)雜

我經(jīng)?？吹剑瑥臄?shù)據(jù)庫(kù)中捕捉到的一條SQL語(yǔ)句打印出來(lái)有2張A4紙這么長(zhǎng)。一般來(lái)說(shuō)這么復(fù)雜的語(yǔ)句通常都是有問(wèn)題的。我拿著這2頁(yè)長(zhǎng)的SQL語(yǔ)句去請(qǐng)教原作者，結(jié)果他說(shuō)時(shí)間太長(zhǎng)，他一時(shí)也看不懂了。可想而知，連原作者都有可能看糊涂的SQL語(yǔ)句，數(shù)據(jù)庫(kù)也一樣會(huì)看糊涂。

一般，將一個(gè)Select語(yǔ)句的結(jié)果作為子集，然后從該子集中再進(jìn)行查詢，這種一層嵌套語(yǔ)句還是比較常見(jiàn)的，但是根據(jù)經(jīng)驗(yàn)，超過(guò)3層嵌套，查詢優(yōu)化器就很容易給出錯(cuò)誤的執(zhí)行計(jì)劃。因?yàn)樗焕@暈了。像這種類似人工智能的東西，終究比人的分辨力要差些，如果人都看暈了，我可以保證數(shù)據(jù)庫(kù)也會(huì)暈的。

另外，執(zhí)行計(jì)劃是可以被重用的，越簡(jiǎn)單的SQL語(yǔ)句被重用的可能性越高。而復(fù)雜的SQL語(yǔ)句只要有一個(gè)字符發(fā)生變化就必須重新解析，然后再把這一大堆垃圾塞在內(nèi)存里。可想而知，數(shù)據(jù)庫(kù)的效率會(huì)何等低下。

4、 使用“臨時(shí)表”暫存中間結(jié)果

簡(jiǎn)化SQL語(yǔ)句的重要方法就是采用臨時(shí)表暫存中間結(jié)果，但是，臨時(shí)表的好處遠(yuǎn)遠(yuǎn)不止這些，將臨時(shí)結(jié)果暫存在臨時(shí)表，后面的查詢就在tempdb中了，這可以避免程序中多次掃描主表，也大大減少了程序執(zhí)行中“共享鎖”阻塞“更新鎖”，減少了阻塞，提高了并發(fā)性能。

5、 OLTP系統(tǒng)SQL語(yǔ)句必須采用綁定變量

以上兩句語(yǔ)句，查詢優(yōu)化器認(rèn)為是不同的SQL語(yǔ)句，需要解析兩次。如果采用綁定變量

select * from orderheader where changetime > @chgtime @chgtime變量可以傳入任何值，這樣大量的類似查詢可以重用該執(zhí)行計(jì)劃了，這可以大大降低數(shù)據(jù)庫(kù)解析SQL語(yǔ)句的負(fù)擔(dān)。一次解析，多次重用，是提高數(shù)據(jù)庫(kù)效率的原則。

6、 綁定變量窺測(cè)

事物都存在兩面性，綁定變量對(duì)大多數(shù)OLTP處理是適用的，但是也有例外。比如在where條件中的字段是“傾斜字段”的時(shí)候。

“傾斜字段”指該列中的絕大多數(shù)的值都是相同的，比如一張人口調(diào)查表，其中“民族”這列，90%以上都是漢族。那么如果一個(gè)SQL語(yǔ)句要查詢30歲的漢族人口有多少，那“民族”這列必然要被放在where條件中。這個(gè)時(shí)候如果采用綁定變量@nation會(huì)存在很大問(wèn)題。

試想如果@nation傳入的第一個(gè)值是“漢族”，那整個(gè)執(zhí)行計(jì)劃必然會(huì)選擇表掃描。然后，第二個(gè)值傳入的是“布依族”，按理說(shuō)“布依族”占的比例可能只有萬(wàn)分之一，應(yīng)該采用索引查找。但是，由于重用了第一次解析的“漢族”的那個(gè)執(zhí)行計(jì)劃，那么第二次也將采用表掃描方式。這個(gè)問(wèn)題就是著名的“綁定變量窺測(cè)”，建議對(duì)于“傾斜字段”不要采用綁定變量。

7、 只在必要的情況下才使用begin tran

SQL Server中一句SQL語(yǔ)句默認(rèn)就是一個(gè)事務(wù)，在該語(yǔ)句執(zhí)行完成后也是默認(rèn)commit的。其實(shí)，這就是begin tran的一個(gè)最小化的形式，好比在每句語(yǔ)句開(kāi)頭隱含了一個(gè)begin tran，結(jié)束時(shí)隱含了一個(gè)commit。

有些情況下，我們需要顯式聲明begin tran，比如做“插、刪、改”操作需要同時(shí)修改幾個(gè)表，要求要么幾個(gè)表都修改成功，要么都不成功。begin tran 可以起到這樣的作用，它可以把若干SQL語(yǔ)句套在一起執(zhí)行，最后再一起commit。好處是保證了數(shù)據(jù)的一致性，但任何事情都不是完美無(wú)缺的。Begin tran付出的代價(jià)是在提交之前，所有SQL語(yǔ)句鎖住的資源都不能釋放，直到commit掉。

可見(jiàn)，如果Begin tran套住的SQL語(yǔ)句太多，那數(shù)據(jù)庫(kù)的性能就糟糕了。在該大事務(wù)提交之前，必然會(huì)阻塞別的語(yǔ)句，造成block很多。

Begin tran使用的原則是，在保證數(shù)據(jù)一致性的前提下，begin tran 套住的SQL語(yǔ)句越少越好！有些情況下可以采用觸發(fā)器同步數(shù)據(jù)，不一定要用begin tran。

8、 一些SQL查詢語(yǔ)句應(yīng)加上nolock

在SQL語(yǔ)句中加nolock是提高SQL Server并發(fā)性能的重要手段，在oracle中并不需要這樣做，因?yàn)閛racle的結(jié)構(gòu)更為合理，有undo表空間保存“數(shù)據(jù)前影”，該數(shù)據(jù)如果在修改中還未commit，那么你讀到的是它修改之前的副本，該副本放在undo表空間中。這樣，oracle的讀、寫(xiě)可以做到互不影響，這也是oracle 廣受稱贊的地方。SQL Server 的讀、寫(xiě)是會(huì)相互阻塞的，為了提高并發(fā)性能，對(duì)于一些查詢，可以加上nolock，這樣讀的時(shí)候可以允許寫(xiě)，但缺點(diǎn)是可能讀到未提交的臟數(shù)據(jù)。使用 nolock有3條原則。

(1)查詢的結(jié)果用于“插、刪、改”的不能加nolock ！
(2)查詢的表屬于頻繁發(fā)生頁(yè)分裂的，慎用nolock ！
(3)使用臨時(shí)表一樣可以保存“數(shù)據(jù)前影”，起到類似oracle的undo表空間的功能，

能采用臨時(shí)表提高并發(fā)性能的，不要用nolock 。

9、 聚集索引沒(méi)有建在表的順序字段上，該表容易發(fā)生頁(yè)分裂

比如訂單表，有訂單編號(hào)orderid，也有客戶編號(hào)contactid，那么聚集索引應(yīng)該加在哪個(gè)字段上呢？對(duì)于該表，訂單編號(hào)是順序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，這樣不容易經(jīng)常產(chǎn)生頁(yè)分裂。然而，由于大多數(shù)查詢都是根據(jù)客戶編號(hào)來(lái)查的，因此，將聚集索引加在contactid上才有意義。而contactid對(duì)于訂單表而言，并非順序字段。

比如“張三”的“contactid”是001，那么“張三”的訂單信息必須都放在這張表的第一個(gè)數(shù)據(jù)頁(yè)上，如果今天“張三”新下了一個(gè)訂單，那該訂單信息不能放在表的最后一頁(yè)，而是第一頁(yè)！如果第一頁(yè)放滿了呢？很抱歉，該表所有數(shù)據(jù)都要往后移動(dòng)為這條記錄騰地方。

SQL Server的索引和Oracle的索引是不同的，SQL Server的聚集索引實(shí)際上是對(duì)表按照聚集索引字段的順序進(jìn)行了排序，相當(dāng)于oracle的索引組織表。SQL Server的聚集索引就是表本身的一種組織形式，所以它的效率是非常高的。也正因?yàn)榇?，插入一條記錄，它的位置不是隨便放的，而是要按照順序放在該放的數(shù)據(jù)頁(yè)，如果那個(gè)數(shù)據(jù)頁(yè)沒(méi)有空間了，就引起了頁(yè)分裂。所以很顯然，聚集索引沒(méi)有建在表的順序字段上，該表容易發(fā)生頁(yè)分裂。

曾經(jīng)碰到過(guò)一個(gè)情況，一位哥們的某張表重建索引后，插入的效率大幅下降了。估計(jì)情況大概是這樣的。該表的聚集索引可能沒(méi)有建在表的順序字段上，該表經(jīng)常被歸檔，所以該表的數(shù)據(jù)是以一種稀疏狀態(tài)存在的。比如張三下過(guò)20張訂單，而最近3個(gè)月的訂單只有5張，歸檔策略是保留3個(gè)月數(shù)據(jù)，那么張三過(guò)去的 15張訂單已經(jīng)被歸檔，留下15個(gè)空位，可以在insert發(fā)生時(shí)重新被利用。在這種情況下由于有空位可以利用，就不會(huì)發(fā)生頁(yè)分裂。但是查詢性能會(huì)比較低，因?yàn)椴樵儠r(shí)必須掃描那些沒(méi)有數(shù)據(jù)的空位。

重建聚集索引后情況改變了，因?yàn)橹亟ň奂饕褪前驯碇械臄?shù)據(jù)重新排列一遍，原來(lái)的空位沒(méi)有了，而頁(yè)的填充率又很高，插入數(shù)據(jù)經(jīng)常要發(fā)生頁(yè)分裂，所以性能大幅下降。

對(duì)于聚集索引沒(méi)有建在順序字段上的表，是否要給與比較低的頁(yè)填充率？是否要避免重建聚集索引？是一個(gè)值得考慮的問(wèn)題！

10、加nolock后查詢經(jīng)常發(fā)生頁(yè)分裂的表，容易產(chǎn)生跳讀或重復(fù)讀

加nolock后可以在“插、刪、改”的同時(shí)進(jìn)行查詢，但是由于同時(shí)發(fā)生“插、刪、改”，在某些情況下，一旦該數(shù)據(jù)頁(yè)滿了，那么頁(yè)分裂不可避免，而此時(shí)nolock的查詢正在發(fā)生，比如在第100頁(yè)已經(jīng)讀過(guò)的記錄，可能會(huì)因?yàn)轫?yè)分裂而分到第101頁(yè)，這有可能使得nolock查詢?cè)谧x101頁(yè)時(shí)重復(fù)讀到該條數(shù)據(jù)，產(chǎn)生“重復(fù)讀”。同理，如果在100頁(yè)上的數(shù)據(jù)還沒(méi)被讀到就分到99頁(yè)去了，那nolock查詢有可能會(huì)漏過(guò)該記錄，產(chǎn)生“跳讀”。

上面提到的哥們，在加了nolock后一些操作出現(xiàn)報(bào)錯(cuò)，估計(jì)有可能因?yàn)閚olock查詢產(chǎn)生了重復(fù)讀，2條相同的記錄去插入別的表，當(dāng)然會(huì)發(fā)生主鍵沖突。

11、使用like進(jìn)行模糊查詢時(shí)應(yīng)注意

有的時(shí)候會(huì)需要進(jìn)行一些模糊查詢比如
select * from contact where username like ‘%yue%'

關(guān)鍵詞%yue%，由于yue前面用到了“%”，因此該查詢必然走全表掃描，除非必要，否則不要在關(guān)鍵詞前加%，

12、數(shù)據(jù)類型的隱式轉(zhuǎn)換對(duì)查詢效率的影響

sql server2000的數(shù)據(jù)庫(kù)，我們的程序在提交sql語(yǔ)句的時(shí)候，沒(méi)有使用強(qiáng)類型提交這個(gè)字段的值，由sql server 2000自動(dòng)轉(zhuǎn)換數(shù)據(jù)類型，會(huì)導(dǎo)致傳入的參數(shù)與主鍵字段類型不一致，這個(gè)時(shí)候sql server 2000可能就會(huì)使用全表掃描。Sql2005上沒(méi)有發(fā)現(xiàn)這種問(wèn)題，但是還是應(yīng)該注意一下。

13、SQL Server 表連接的三種方式

(1) Merge Join
(2) Nested Loop Join
(3) Hash Join

SQL Server 2000只有一種join方式——Nested Loop Join，如果A結(jié)果集較小，那就默認(rèn)作為外表，A中每條記錄都要去B中掃描一遍，實(shí)際掃過(guò)的行數(shù)相當(dāng)于A結(jié)果集行數(shù)x B結(jié)果集行數(shù)。所以如果兩個(gè)結(jié)果集都很大，那Join的結(jié)果很糟糕。

SQL Server 2005新增了Merge Join，如果A表和B表的連接字段正好是聚集索引所在字段，那么表的順序已經(jīng)排好，只要兩邊拼上去就行了，這種join的開(kāi)銷相當(dāng)于A表的結(jié)果集行數(shù)加上B表的結(jié)果集行數(shù)，一個(gè)是加，一個(gè)是乘，可見(jiàn)merge join 的效果要比Nested Loop Join好多了。

如果連接的字段上沒(méi)有索引，那SQL2000的效率是相當(dāng)?shù)偷?，而SQL2005提供了Hash join，相當(dāng)于臨時(shí)給A，B表的結(jié)果集加上索引，因此SQL2005的效率比SQL2000有很大提高，我認(rèn)為，這是一個(gè)重要的原因。

總結(jié)一下，在表連接時(shí)要注意以下幾點(diǎn)：

(1) 連接字段盡量選擇聚集索引所在的字段
(2) 仔細(xì)考慮where條件，盡量減小A、B表的結(jié)果集
(3) 如果很多join的連接字段都缺少索引，而你還在用SQL Server 2000，趕緊升級(jí)吧。