一、影響速度的因素
- 沒有索引或者沒有用到索引（這是查詢慢最常見的問題，是程序設計的缺陷）
I/O吞吐量小，形成了瓶頸效應- 沒有創建計算列導致查詢不優化
- 內存不足
- 網絡速度慢
- 查詢出的數據量過大（可以采用多次查詢，其他的方法降低數據量）
- 鎖或者死鎖（這也是查詢慢最常見的問題，是程序設計的缺陷）
sp_lock，sp_who，活動的用戶查看，原因是讀寫競爭資源- 返回了不必要的行和列
- 查詢語句不好，沒有優化
二、查詢優化方法
- 把數據、日志、索引放到不同的
I/O設備上，增加讀取速度，以前可以將Tempdb應放在RAID0上，SQL2000不在支持。數據量（尺寸）越大，提高I/O越重要 - 縱向、橫向分割表，減少表的尺寸(
sp_spaceuse) - 升級硬件
- 根據查詢條件，建立索引，優化索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當（最好是使用默認值0）。索引應該盡量小，使用字節數小的列建索引好（參照索引的創建），不要對有限的幾個值的字段建單一索引如性別字段
- 提高網速
- 擴大服務器的內存。配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置。可考慮將虛擬內存大小設置為計算機中安裝的物理內存的1.5倍。如果另外安裝了全文檢索功能，並打算運行
Microsoft搜索服務以便執行全文索引和查詢，可考慮：將虛擬內存大小配置為至少是計算機中安裝的物理內存的3倍。將SQL Server max server memory服務器配置選項配置為物理內存的1.5倍（虛擬內存大小設置的一半） - 增加服務器
CPU個數;但是必須明白並行處理串行處理更需要資源例如內存。使用並行還是串行程是SQL Server自動評估選擇的。單個任務分解成多個任務，就可以在處理器上運行。例如耽擱查詢的排序、連接、掃描和GROUP BY字句同時執行，SQL Server根據系統的負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢最適合並行處理。但是更新操作UPDATE，INSERT，DELETE還不能並行處理 - 如果是使用
LIKE進行查詢的話，簡單的使用INDEX是不行的，但是全文索引耗空間。LIKE 'a%'使用索引LIKE '%a'不使用索引用LIKE '%a%'查詢時，查詢耗時和字段值總長度成正比，所以不能用CHAR類型，而用VARCHAR。對於字段的值很長的建全文索引 DB Server和Application Server分離，OLTP和OLAP分離- 分布式分區視圖可用於實現數據庫服務器聯合體。聯合體是一組分開管理的服務器，但它們相互協作分擔系統的處理負荷。這種通過分區數據形成數據庫服務器聯合體的機制能夠擴大一組服務器，以支持大型的多層WEB站點的處理需要。有關更多信息，參見設計聯合數據庫服務器。（參照SQL幫助文件【分區視圖】）
- 在實現分區視圖之前，必須先水平分區表
- 在創建成員表后，在每個成員服務器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣，引用分布式分區視圖名的查詢可以在任何一個成員服務器上運行。系統操作如同每個成員服務器上都有一個原始表的復本一樣，但其實每個服務器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。
- 重建索引
DBCC REINDEX，DBCC INDEXDEFRAG，收縮數據和日志DBCC SHRINKDB，DBCC SHRINKFILE設置自動收縮日志對於大的數據庫不要設置數據庫自動增長，它會降低服務器的性能。在T-SQL的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計划的過程是這樣的：
- 查詢語句的詞法、語法檢查
- 將語句提交給DBMS的查詢優化器
- 優化器做代數優化和存取路徑的優化
- 由預編譯模塊生成查詢規划
- 然后在合適的時間提交給系統處理執行
- 最后將執行結果返回給用戶，其次，看一下SQL Server的數據存放的結構：一個頁面的大小為8K(8060)字節，8個頁面為一個盤區，按照
B樹存放。
COMMIT和ROLLBACK的區別。ROLLBACK回滾所有的事物，COMMIT提交當前的事物。沒有必要在動態SQL里寫事物，如果要寫請寫在外面，如：begin tran exec(@s) commit trans或者將動態SQL寫成函數或者存儲過程。- 在查詢
SELECT語句中用WHERE字句限制返回的行數，避免表掃描，如果返回不必要的數據，浪費了服務器的I/O資源，加重了網絡的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表，后果嚴重。 - SQL的注釋申明對執行沒有任何影響
- 盡可能不使用光標，它占用大量的資源。如果需要
ROW-BY-ROW地執行，盡量采用非光標技術，如：在客戶端循環，用臨時表，TABLE變量，用子查詢，用CASe語句等等。游標可以按照它所支持的提取選項進行分類：只進必須按照從第一行到最后一行的順序提取行。FETCHNEXT是唯一允許的提取操作，也是默認方式。可滾動性可以在游標中任何地方隨機提取任意行。游標的技術在SQL2000下變得功能很強大，他的目的是支持循環。有四個並發選項：
READ_ONLY：不允許通過游標定位更新(UPDATE)，且在組成結果集的行中沒有鎖。OPTIMISTIC WITH VALUES：樂觀並發控制是事務控制理論的一個標准部分。樂觀並發控制用於這樣的情形，即在打開游標及更新行的間隔中，只有很小的機會讓第二個用戶更新某一行。當某個游標以此選項打開時，沒有鎖控制其中的行，這將有助於最大化其處理能力。如果用戶試圖修改某一行，則此行的當前值會與最后一次提取此行時獲取的值進行比較。如果任何值發生改變，則服務器就會知道其他人已更新了此行，並會返回一個錯誤。如果值是一樣的，服務器就執行修改。選擇這個並發選項OPTIMISTIC WITH ROW VERSIONING：此樂觀並發控制選項基於行版本控制。使用行版本控制，其中的表必須具有某種版本標識符，服務器可用它來確定該行在讀入游標后是否有所更改。
在SQL Server中，這個性能由timestamp數據類型提供，它是一個二進制數字，表示數據庫中更改的相對順序。每個數據庫都有一個全局當前時間戳值：@@DBTS。每次以任何方式更改帶有timestamp列的行時，SQL Server先在時間戳列中存儲當前的@@DBTS值，然后增加@@DBTS的值。如果某個表具有timestamp列，則時間戳會被記到行級。服務器就可以比較某行的當前時間戳值和上次提取時所存儲的時間戳值，從而確定該行是否已更新。服務器不必比較所有列的值，只需比較timestamp列即可。如果應用程序對沒有timestamp列的表要求基於行版本控制的樂觀並發，則游標默認為基於數值的樂觀並發控制。SCROLL LOCKS：這個選項實現悲觀並發控制。在悲觀並發控制中，在把數據庫的行讀入游標結果集時，應用程序將試圖鎖定數據庫行。在使用服務器游標時，將行讀入游標時會在其上放置一個更新鎖。如果在事務內打開游標，則該事務更新鎖將一直保持到事務被提交或回滾；當提取下一行時，將除去游標鎖。如果在事務外打開游標，則提取下一行時，鎖就被丟棄。因此，每當用戶需要完全的悲觀並發控制時，游標都應在事務內打開。更新鎖將阻止任何其它任務獲取更新鎖或排它鎖，從而阻止其它任務更新該行。
然而，更新鎖並不阻止共享鎖，所以它不會阻止其它任務讀取行，除非第二個任務也在要求帶更新鎖的讀取。滾動鎖根據在游標定義的SELECT語句中指定的鎖提示，這些游標並發選項可以生成滾動鎖。滾動鎖在提取時在每行上獲取，並保持到下次提取或者游標關閉，以先發生者為准。下次提取時，服務器為新提取中的行獲取滾動鎖，並釋放上次提取中行的滾動鎖。滾動鎖獨立於事務鎖，並可以保持到一個提交或回滾操作之后。如果提交時關閉游標的選項為關，則COMMIT語句並不關閉任何打開的游標，而且滾動鎖被保留到提交之后，以維護對所提取數據的隔離。所獲取滾動鎖的類型取決於游標並發選項和游標SELECT語句中的鎖提示。
| 鎖提示 | 只讀 | 樂觀數值 | 樂觀行版本控制 | 鎖定 |
|---|---|---|---|---|
| 無提示 | 未鎖定 | 未鎖定 | 未鎖定 | 更新 |
| NOLOCK | 未鎖定 | 未鎖定 | 未鎖定 | 未鎖定 |
| HOLDLOCK | 共享 | 共享 | 共享 | 更新 |
| UPDLOCK | 錯誤 | 更新 | 更新 | 更新 |
| TABLOCKX | 錯誤 | 未鎖定 | 未鎖定 | 更新 |
| 其它 | 未鎖定 | 未鎖定 | 未鎖定 | 更新 |
指定
NOLOCK提示將使指定了該提示的表在游標內是只讀的。
- 用
Profiler來跟蹤查詢，得到查詢所需的時間，找出SQL的問題所在;用索引優化器優化索引 - 注意
UNION和UNION ALL的區別。UNION自動去重，效率低。 - 注意使用
DISTINCT，在沒有必要時不要用，它同UNION一樣會使查詢變慢。重復的記錄在查詢里是沒有問題的 - 查詢時不要返回不需要的行和列
- 用
sp_configure、SET QUERY_GOVERNOR_COST_LIMIT或者SET QUERY_GOVERNOR_COST_LIMIT來限制查詢消耗的資源。當評估查詢消耗的資源超出限制時，服務器自動取消查詢，在查詢之前就扼殺掉。SET LOCK_TIMEOUT設置鎖的時間 - 用
SELECT TOP 100/10 PERCENT來限制用戶返回的行數或者SET ROWCOUNT來限制操作的行 - 在SQL2000以前，一般不要用如下的字句：
"IS NULL"，"<>"，"!="，"!>"，"!<"，"NOT"，"NOT EXISTS"，"NOT IN"，"NOT LIKE"，"LIKE '%500'"，因為他們不走索引全是表掃描。也不要在WHERE字句中的列名加函數，如CONVERT，SUBSTRING等，如果必須用函數的時候，創建計算列再創建索引來替代，還可以變通寫法：WHERE SUBSTRING(firstname，1，1)='m'改為WHERE firstname LIKE 'm%'（索引掃描），一定要將函數和列名分開。並且索引不能建得太多和太大。NOT IN會多次掃描表，使用EXISTS、NOT EXISTS、IN、LEFT OUTER JOIN來替代，特別是左連接，而EXISTS比IN更快，最慢的是NOT操作，如果列的值含有空，以前它的索引不起作用，現在2000的優化器能夠處理了。相同的是IS NULL，NOT，NOT EXISTS，NOT IN能優化它，而”<>”等還是不能優化，用不到索引。 - 使用
Query Analyzer，查看SQL語句的查詢計划和評估分析是否是優化的SQL。一般的20%的代碼占據了80%的資源，我們優化的重點是這些慢的地方。 - 如果使用了
IN或者OR等時發現查詢沒有走索引，使用顯示申明指定索引：SELECT * FROM PersonMember(INDEX=IX_Title) WHERE processid IN('男','女') - 將需要查詢的結果預先計算好放在表中，查詢的時候再
SELECT - MIN()和MAX()能使用到合適的索引
- 數據庫有一個原則是代碼離數據越近越好，所以優先選擇
Default，依次為Rules，Triggers，Constraint（約束如外健主健Check/UNIQUE……，數據類型的最大長度等等都是約束），PROCEDURE這樣不僅維護工作小，編寫程序質量高，並且執行的速度快。 - 如果要插入大的二進制值到
Image列，使用存儲過程，千萬不要用內嵌INSERT來插入。因為這樣應用程序首先將二進制值轉換成字符串（尺寸是它的兩倍），服務器受到字符后又將他轉換成二進制值，存儲過程就沒有這些動作，方法：CREATE PROCEDURE p_insert AS INSERT INTO TABLE(Fimage)VALUES(@image)，在前台調用這個存儲過程傳入二進制參數，這樣處理速度明顯改善。 BETWEEN在某些時候比IN速度更快，BETWEEN能夠更快地根據索引找到范圍。用查詢優化器可見到差別。SELECT * FROM chineseresume WHERE title IN ('男'，'女')與SELECT * FROM chineseresume WHERE BETWEEN '男' AND '女'是一樣的。由於IN會在比較多次，所以有時會慢些。- 在必要是對全局或者局部臨時表創建索引，有時能夠提高速度，但不是一定會這樣，因為索引也耗費大量的資源。他的創建同是實際表一樣。
- 不要建沒有作用的事物例如產生報表時，浪費資源。只有在必要使用事物時使用它。
- 用
OR的字句可以分解成多個查詢，並且通過UNION連接多個查詢。他們的速度只同是否使用索引有關，如果查詢需要用到聯合索引，用UNION ALL執行的效率更高，多個OR的字句沒有用到索引，改寫成UNION的形式再試圖與索引匹配。一個關鍵的問題是否用到索引。 - 盡量少用視圖，它的效率低。對視圖操作比直接對表操作慢，可以用
STOREDPROCEDURE來代替它。特別是不要用視圖嵌套，增加了尋找原始資料的難度。我們看視圖的本質：它是存放在服務器上的被優化好了的已經產生了查詢規划的SQL。對單個表檢索數據時，不要使用指向多個表的視圖，直接從表檢索或者僅僅包含這個表的視圖上讀，否則增加了不必要的開銷，查詢受到干擾，為了加快視圖的查詢，SQL Server增加了視圖索引的功能。 - 沒有必要時不要用
DISTINCT和ORDERBY，這些動作可以改在客戶端執行。它們增加了額外的開銷。這同UNION和UNIONALL一樣的道理。SELECT TOP 20 ad.companyname，comid，position，ad.referenceid，worklocation，CONVERT(VARCHAR(10)，ad.postDate，120) AS postDate1，workyear，degreeDESCription FROM 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 - 在
IN后面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最后面，減少判斷的次數 - 當用
SELECT INTO時，它會鎖住系統表(sysobjects，sysindexes等等)，阻塞其他的連接的存取。創建臨時表時用顯示申明語句，而不是SELECT INTO droptablet_lxhbegintran SELECT * INTO t_lxh FROM chineseresume WHERE name='XYZ'。在另一個連接中SELECT * FROM sysobjects可以看到SELECT INTO會鎖住系統表，CREATE TABLE也會鎖系統表(不管是臨時表還是系統表)。所以千萬不要在事物內使用它！！！這樣的話如果是經常要用的臨時表請使用實表，或者臨時表變量。 - 一般在
GROUP BY個HAVING字句之前就能剔除多余的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：SELECT的WHERE字句選擇所有合適的行，GROUP BY用來分組個統計行，HAVING字句用來剔除多余的分組。這樣GROUP BY個HAVING的開銷小，查詢快，對於大的數據行進行分組和HAVING十分消耗資源。如果GROUP BY的目的不包括計算，只是分組，那么用DISTINCT更快 - 一次更新多條記錄比分多次更新每次一條快，就是說批處理好
- 少用臨時表，盡量用結果集和
TABLE類性的變量來代替它，TABLE類型的變量比臨時表好 - 在SQL2000下，計算字段是可以索引的，需要滿足的條件如下：
- 計算字段的表達是確定的
- 不能用在
TEXT，Ntext，Image數據類型- 必須配制如下選項
ANSI_NULLS=ON，ANSI_PADDINGS=ON
- 盡量將數據的處理工作放在服務器上，減少網絡的開銷，如使用存儲過程。存儲過程是編譯好、優化過、並且被組織到一個執行規划里、且存儲在數據庫中的SQL語句，是控制流語言的集合，速度當然快。反復執行的動態SQL，可以使用臨時存儲過程，該過程（臨時表）被放在
Tempdb中。以前由於SQL Server對復雜的數學計算不支持，所以不得不將這個工作放在其他的層上而增加網絡的開銷。SQL2000支持UDFs，現在支持復雜的數學計算，函數的返回值不要太大，這樣的開銷很大。用戶自定義函數象光標一樣執行的消耗大量的資源，如果返回大的結果采用存儲過程 - 不要在一句話里再三的使用相同的函數，浪費資源，將結果放在變量里再調用更快
SELECT COUNT(*)的效率教低，盡量變通他的寫法，而EXISTS快，同時請注意區別：SELECT COUNT(Field of null) FROM TABLE和SELECT COUNT(Field of not null) FROM TABLE的返回值是不同的。- 當服務器的內存夠多時，【配制線程數量=最大連接數+5】，這樣能發揮最大的效率；否則使用【配制線程數量<最大連接數】，啟用SQL Server的線程池來解決，如果還是【數量=最大連接數+5】，嚴重的損害服務器的性能。
- 按照一定的次序來訪問你的表。如果你先鎖住表A，再鎖住表B，那么在所有的存儲過程中都要按照這個順序來鎖定它們。如果你（不經意的）某個存儲過程中先鎖定表B，再鎖定表A，這可能就會導致一個死鎖。如果鎖定順序沒有被預先詳細的設計好，死鎖很難被發現
- 通過
SQL Server Performance Monitor監視相應硬件的負載Memory：PageFaults/sec計數器如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。Process：
%DPCTime指在范例間隔期間處理器用在緩延程序調用(DPC)接收和提供服務的百分比。(DPC正在運行的為比標准間隔優先權低的間隔)。由於DPC是以特權模式執行的，DPC時間的百分比為特權時間百分比的一部分。這些時間單獨計算並且不屬於間隔計算總數的一部分。這個總數顯示了作為實例時間百分比的平均忙時。%ProcessorTime計數器 如果該參數值持續超過95%，表明瓶頸是CPU。可以考慮增加一個處理器或換一個更快的處理器。%PrivilegedTime指非閑置處理器時間用於特權模式的百分比。(特權模式是為操作系統組件和操縱硬件驅動程序而設計的一種處理模式。它允許直接訪問硬件和所有內存。另一種模式為用戶模式，它是一種為應用程序、環境分系統和整數分系統設計的一種有限處理模式。操作系統將應用程序線程轉換成特權模式以訪問操作系統服務)。特權時間的%包括為間斷和DPC提供服務的時間。特權時間比率高可能是由於失敗設備產生的大數量的間隔而引起的。這個計數器將平均忙時作為樣本時間的一部分顯示。%UserTime表示耗費CPU的數據庫操作，如排序，執行Aggregate Functions等。如果該值很高，可考慮增加索引，盡量使用簡單的表聯接，水平分割大表格等方法來降低該值。PhysicalDisk：Curretn Disk Queue Length計數器該值應不超過磁盤數的1.5~2倍。要提高性能，可增加磁盤。SQLServer：Cache Hit Ratio計數器該值越高越好。如果持續低於80%，應考慮增加內存。注意該參數值是從SQL Server啟動后，就一直累加記數，所以運行經過一段時間后，該值將不能反映系統當前值。
- 分析
SELECT emp_name FROM employee WHERE salary > 3000在此語句中若salary是FLOAT類型的，則優化器對其進行優化為CONVERT(FLOAT，3000)，因為3000是個整數，我們應在編程時使用3000.0而不要等運行時讓DBMS進行轉化。同樣字符和整型數據的轉換。
三、千萬級數據優化
- 對查詢進行優化，應盡量避免全表掃描，首先應考慮在
where及order by涉及的列上建立索引。 - 應盡量避免在
where子句中對字段進行null值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：select id from t where num is null可以在num上設置默認值0，確保表中num列沒有null值，然后這樣查詢：select id from t where num=0 - 應盡量避免在
where子句中使用!=或<>操作符，否則引擎將放棄使用索引而進行全表掃描。 - 應盡量避免在
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 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- 下面的查詢也將導致全表掃描：
select id from t where name like '%李%'若要提高效率，可以考慮全文檢索。 - 如果在
where子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變量，但優化程序不能將訪問計划的選擇推遲到運行時；它必須在編譯時進行選擇。然``而，如果在編譯時建立訪問計划，變量的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：select id from t where num=@num可以改為強制查詢使用索引：select id from t with(index(索引名)) where num=@num - 應盡量避免在
where子句中對字段進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：select id from t where num/2=100應改為:select id from t where num=100*2 - 應盡量避免在
where子句中對字段進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：select id from t where substring(name,1,3)='abc'，name以abc開頭的id應改為:select id from t where name like 'abc%' - 不要在
where子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。 - 在使用索引字段作為條件時，如果該索引是復合索引，那么必須使用到該索引中的第一個字段作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓字段順序與索引順序相一致。
- 不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：create table #t(…) - 很多時候用
exists代替in是一個好的選擇：select num from a where num in(select num from b)用下面的語句替換：select num from a where exists(select 1 from b where num=a.num) - 並不是所有索引對查詢都有效，
SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對查詢效率起不了作用。 - 索引並不是越多越好，索引固然可以提高相應的
select的效率，但同時也降低了insert及update的效率，因為insert或update時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。 - 應盡可能的避免更新
clustered索引數據列，因為clustered索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新clustered索引數據列，那么需要考慮是否應將該索引建為clustered索引。 - 盡量使用數字型字段，若只含數值信息的字段盡量不要設計為字符型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對於數字型而言只需要比較一次就夠了。
- 盡可能的使用
varchar/nvarchar代替char/nchar，因為首先變長字段存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的字段內搜索效率顯然要高些。 - 任何地方都不要使用
select * from t，用具體的字段列表代替“*”，不要返回用不到的任何字段。 - 盡量使用表變量來代替臨時表。如果表變量包含大量數據，請注意索引非常有限（只有主鍵索引）。
- 避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
- 臨時表並不是不可使用，適當地使用它們可以使某些例程更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
- 在新建臨時表時，如果一次性插入數據量很大，那么可以使用
select into代替create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然后insert。 - 如果使用到了臨時表，在存儲過程的最后務必將所有的臨時表顯式刪除，先
truncate table，然后drop table，這樣可以避免系統表的較長時間鎖定。 - 盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那么就應該考慮改寫。
- 使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
- 與臨時表一樣，游標並不是不可使用。對小型數據集使用
FAST_FORWARD游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括“合計”的例程通常要比使用游標執行的速度快。如果開發時間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。 - 在所有的存儲過程和觸發器的開始處設置
SET NOCOUNT ON，在結束時設置SET NOCOUNT OFF。無需在執行存儲過程和觸發器的每個語句后向客戶端發送DONE_IN_PROC消息。 - 盡量避免大事務操作，提高系統並發能力。
- 盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。