A. sql調優的幾種方式
你好，
SQL優化的一些方法
1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描。
3.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
4.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描。
5.in 和 not in 也要慎用，否則會導致全表掃描，
6.下面的查詢也將導致全表掃描：
select id from t where name like '%abc%'
7.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。
8.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。
9.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
10.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
B. sql server性能調優實戰 這本書怎樣
本書是一線DBA技術專家精心之作。積作者多年的經驗結晶和*佳實踐。
也是目前市場上為數不多通過存儲原理來講解性能優化，剖析SQL
Server架構，從而幫助讀者快速高效調優資料庫的圖書。
C. 求助：sqlserver2005如何進行內存優化
訪問量大沒法改變，從程序和SP入手吧，減少程序與DB連接次數,優化程序SQL，。。
D. 如何優化Windows OS使SQL Server性能最優化
怎樣查出SQLServer的性能瓶頸QLServer性能監控這套性能優化的清單將至少准科學的幫助你找出你的SQLServer任何明顯的性能問題。說是這樣說，SQLServer的性能調優仍然是很困難的。我試圖用這套清單去找出「容易」的sqlserver性能問題，困難的留待稍後。我這樣做是因為很容易將容易和困難的的性能調優問題搞混。通過列出一個「容易」的性能調優范圍，就很容易的將這些問題解決，一旦解決了這些容易的問題，那麼你就能集中去解決更困難的問題。使用這個SQLServer性能調優清單的一個好處是，它將不僅僅告訴你目前最容易解決的性能問題是什麼，而且還幫助你正確的去解決。在某種程度上，你可以選擇不同的順序進行。換句話說，你可以故意做出特殊的決定而不是按照清單通常的順序進行。某種意義上說你是對的，不是所有的性能調優建議都適合所有的情形。另外，你的決定是基於你的資源限制，例如沒有足夠的錢去買滿足負荷的硬體。如果真是那樣的話，你就別無選擇了。還有，你的決定可能基於一些政治原因，那是你不得不作出的改變。不管怎樣，你需要知道你能做什麼，使用這個性能調優清單找出你能改變的范圍並做出相應的改變提升你的SQLServer的性能。一般來說，你將在你的每一個SQL伺服器上執行這個清單。如果遇到清單中的一些問題，這會花掉你一些時間。我建議你從目前性能問題最多的的伺服器開始，然後當你有時間的時候按照自己的思路去解決其他伺服器。一旦你完成了，可仍然有很多事情要去做。記住，這些只是一些容易的。一旦你完成了這些容易的，接下來你需要花時間去解決更困難問題。這個是另一篇文章要解決的問題了。怎樣進行你的SQLServer性能調優呢?為了使其變得容易，我把它們分成了以下幾個部分：？使用性能監視器找出硬體瓶頸？SQLServer硬體性能監控列表？操作系統性能監控列表？SQLServer2000配置性能監控列表？資料庫配置設置性能監控列表？索引性能監控列表？應用程序和T-SQL性能監控列表？SQLServer資料庫作業性能監控列表？使用Profiler找出低效的查詢？怎樣最好的實現SQLServer性能監控管理你的SQLServe性能的最好方法是首先回顧上面每一部分的內容，把它們列印出來。然後完成每一部分的內容，寫下你收集到的結果。你也可以按照你喜歡的順序進行。上面的步驟僅僅列出了我執行的順序，因為那樣通常能達到一個比較好的效果。性能監控列表計數器名稱均值最小值最大值Memory:Pages/secMemory:AvailableBytesPhysicalDisk:%DisktimePhysicalDisk:Avg.DiskQueueLengthProcessor:%ProcessorTimeSystem:::UserConnections在上表輸入你的結果.使用性能監視器找出SQLServer硬體瓶頸開始SQLServer性能調優的最佳地方就是從性能監視器（系統監視器）開始。通過一個24小時的周期對一些關鍵的計數器進行監控，你將對你SQLServer伺服器的硬體瓶頸了如指掌。一般來說，使用性能監視器去創建一個一些關鍵的計數器的24小時周期的監控日誌。當你決定創建這個日誌的時候，你需要選擇一個典型的24小時的周期，例如，選擇一個典型的比較忙的日期，而不是周日或節假日。一旦你將這些捕獲的數據形成日誌後，在性能監視器的圖形界面下會顯示計數器的推薦值。你在上表中記下均值、最小值、峰值。做完這些後，用你的結果跟下面的分析比較。通過你的結果和下面的建議值進行比較，你將能快速的找到你的SQLServe正在經歷的潛在的硬體瓶頸。
E. 如何進行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樹存放。
F. Sql server 安全,性能優化的15條方案
1．1 基本概念 與資料庫技術密切相關的基本概念包括：數據、資料庫、資料庫管理系統和資料庫系統四大概念。1. 數據（Data） 數據是對客觀事物的一種描述，是由能被計算機識別與處理的數值、字元等符號構成的集合，即數據是指描述事物的符號記錄。 廣義地說，數據是一種物理符號的序列，用於記錄事物的情況，是對客觀事物及其屬性進行的一種抽象化及符號化的描述。數據的概念應包括數據的內容和形式兩個方面。數據的內容是指所描述的客觀事物的具體特性，也就是通常所說的數據的「值」；數據的形式則是指數據內容所存儲的具體形式，即數據的「類型」。故此，數據可以用數據類型和值來表示。2. 資料庫（Data Base，DB） 資料庫是指長期存儲在計算機內部、有組織的、可共享的數據集合，即在計算機系統中按一定的數據模型組織、存儲和使用的相關聯的數據集合成為資料庫。 資料庫中的數據按照一定的數據模型組織、描述和存儲，具有較小的冗餘度、較高的數據獨立性、易擴展性、集中性和共享性，以文件的形式存儲在存儲介質上的。資料庫中的數據由資料庫管理系統進行統一管理和控制，用戶對資料庫進行的各種數據操作都是通過資料庫管理系統實現。3. 資料庫管理系統（Data Base Management System，DBMS） 資料庫管理系統是資料庫系統的核心，是為資料庫的建立、使用和維護而配置的軟體，是位於操作系統與用戶之間的一層數據管理軟體。主要功能是對資料庫進行定義、操作、控制和管理。1) 數據定義 數據的定義包括：定義構成資料庫結構的外模式、模式和內模式，定義各個外模式和模式之間的映射，定義模式與內模式之間的映射，定義有關的約束條件。2) 數據處理對數據的處理操作主要包括對資料庫數據的檢索、插入、修改和刪除等基本操作。3) 安全管理 對資料庫的安全管理主要體現在：對資料庫進行並發控制、安全性檢查、完整性約束條件的檢查和執行、資料庫的內部維護（如索引、數據字典的自動維護）等。並且能夠管理和監督用戶的許可權，防止擁護有任何破壞或者惡意的企圖。4) 數據的組織、存儲和管理 負責分類地組織、存儲和管理資料庫數據，確定以何種文件結構和存取方式物理地組織數據，如何實現數據之間的聯系，以便提高存儲空間利用以及提高隨機查找、順序查找、增加、刪除和查改等操作的時間效率。5) 建立和維護資料庫 建立資料庫包括資料庫數據的初始化與數據轉換等。維護資料庫包括資料庫的轉儲與恢復、資料庫的重組織與重構造、性能的監視與分析等。6) 數據通信介面提供與其他軟體系統進行通信的功能。4. 資料庫系統（Data Base System，DBS） 資料庫系統指在計算機系統中引入資料庫後的系統構成，一般有資料庫、資料庫管理系統、應用系統、資料庫管理員和用戶構成。1．2 資料庫系統的特點 資料庫系統的點主要有：數據的結構化、高共享性、低冗餘度、易擴充、較高的獨立性（物理數據獨立、邏輯數據獨立）以及數據由DBMS統一管理和控制（數據的安全性Security保護、數據的完整性Integrity保護、並發Concurrency控制、資料庫恢復Recovery）等。第二章 資料庫性能優化 資料庫作為一種獨立的、有組織、的可共享的數據集合，數據的查詢訪問是數據操作中頻度最高的操作。當數據量和訪問頻率達到一定程度的時候，系統的響應速度就至關重要了，這時候就需要對資料庫數據存儲的結構和方式進行優化，使其滿足系統需要的訪問響應速度。2．1 性能影響因素 常見的影響數據訪問速度的因素，有以下幾種：1. 沒有索引或者沒有用到索引 資料庫索引就像書籍中目錄一樣，使用戶在訪問資料庫數據時，不必遍歷所有數據就可以找到需要的數據。創建索引後，可以保證每行數據的唯一性，極大地提高數據檢索效率，這是一中犧牲空間換取性能的方法。沒有索引或者沒有用到索引是數據訪問速度慢最常見的因素，也是程序設計的一個缺陷所在。2. I/O吞吐量小，形成了瓶頸效應 I/O吞吐量是影響數據訪問速度的客觀因素（硬體因素）。在一定的硬體環境下，利用優化的部署方案可適當提高I/O吞吐量。3. 沒有創建計算列導致查詢不優化 計算列是一個比較特殊的列，不填寫任何設計類型，用戶不可以改變該列的值。計算列的值是通過一定的函數公式等以另一個或多個列的值為輸入值計算出的結果。如果沒相應的計算列，在一些數據查詢的時候需要對已有數據進行計算，從而浪費一部分性能。4. 內存不足 對資料庫數據的查詢訪問毫無疑問會佔用大量的內存空間，當內存不足的情況下，數據的訪問速度會受到明顯的影響甚至訪問出現超時情況，是影響數據訪問速度的客觀因素。5. 網路速度慢 網路速度慢是影響數據訪問速度的客觀因素。可通過提高網路訪問的位寬來解決。6. 查詢出的數據量過大 當查詢出的數據量過大時，內存的佔用、系統時間的佔用等都影響數據訪問的速度。可以採用多次查詢、定位查詢、和查詢數據量控制來解決。7. 鎖或者死鎖 鎖或者死鎖在資料庫數據訪問時會造成訪問者等待時間過程或者永久無法獲取到資源。這是查詢慢最常見的因素之一，是程序設計的缺陷，要盡量避免。8. 返回不必要的行和列 在一般的數據查詢中，都盡可能多的獲取數據信息，這樣造成了不必要的數據遍歷，大大的增加了數據訪問的響應的時間。所以在一般的查詢中，盡量查詢少的行和列，將數據遍歷時間降到最低以滿足數據輸出需求。9. 查詢語句不夠優化 在數據查詢訪問過程中，使用最頻繁的是使用自定義的查詢語句進行數據輸出的。所以編寫優化的查詢語句能夠很大程度上提高數據查詢訪問的速度。2．2 性能優化 資料庫性能優化主要是提高數據訪問的速度，即提高資料庫響應速度的性能指標。性能優化主要分為主觀因素和客觀因素兩部分的優化。這里主要針對影響性能的客觀因素進行優化。2．2．1 主觀因素優化 主觀因素主要是指伺服器的硬體環境。主要優化有以下幾個方面：1、 把數據、日誌、索引放到不同的I/O設備上，增加讀取速度，數據量越大，提高I/O吞吐量越重要；2、 縱向、橫向分割表，減少表的尺寸（sp_spaceuse）；3、 升級硬體；4、 提高網路訪問速度；5、 擴大伺服器的內存；配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置，一般設置為物理內存的1.5倍；如果安裝了全文檢索功能，並打算運行Microsoft搜索服務以便執行全文索引和查詢，可考慮將虛擬內存大小設置為至少計算機中物理內存的3倍；6、 增加伺服器CPU個數；其中並行處理比串列處理更需要資源。SQL SERVER根據系統負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢適合並行處理。不過更新操作UPDATE、INSERT、DELETE不能進行並行處理。 2．2．2 客觀因素優化 客觀因素主要指的是由於設計和開發中存在的缺陷和漏洞；主要優化有以下幾個方面：1. 優化索引（1） 根據查詢條件建立優化的索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當（最好是使用默認值0）。索引應該盡量小，使用位元組數小的列建里索引（參照索引的創建），不要對有限的幾個值的欄位建立單一索引（如性別欄位）。（2） 如果使用LIKE進行查詢的話，簡單的使用INDEX是不行的，全文索引又太耗費空間。LIKE 『N%』使用索引，LIKE 『%N』不使用索引。用LIKE『%N%』查詢時，查詢耗時和欄位值總長度成正比，所以不能用CHAR類型而採用VARCHAR。對於欄位的值很長的欄位建立全文索引。（3） 重建索引DBCC REINDEX，DBCC INDEXDEFRAG，收縮數據和日誌DBCC SHRINKDB，DBCC SHRINKFILE。設置自動收縮日誌，對與大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。2. 資料庫部署優化（1） DB SERVER和APPLICATION SERVER分離，OLTP和OLAP分離；（2） 使用分區視圖。分布式分區視圖可用於實現資料庫伺服器聯合體，聯合體是一組分開管理的伺服器，他們互相協作分擔系統的處理負荷。A、在實現分區視圖之前，必須先水平分區表。B、在創建成員表後，在每個伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣引用分布式分區視圖名的查詢可以在任何一個成員伺服器上運行。系統操作如同每個成員伺服器都有一個原始表的復本一樣，不過每個伺服器上其實只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。3. 查詢語句優化 T-SQL的寫法上有很大的講究，DBMS處理查詢計劃的過程是：a、查詢語句的詞法、語法檢查；b、將語句提交給DBMS的查詢優化器；c、優化器做代數優化和存取路徑的優化；d、由預編譯模塊生成查詢規劃；e、在合適的時間提交給系統處理執行；f、將執行結果返回給用戶。（1） COMMIT和ROLLBACK的區別：ROLLBACK回滾所有的事務；COMMIT提交當前的事務。在動態語句中寫事務，請將事務寫在外面，如：BEGIN TRAN EXEC（@SQL） COMMIT TRANS或者將動態SQL寫成函數或者存儲過程。（2） 在大數據兩的查詢輸出SELECT語句中盡量不要使用自定義函數，調用自定義函數的函數時系統調用是一個迭代過程，很影響查詢輸出性能的。在查詢欄位時盡可能使用小欄位兩輸出，並在WHERE子句或者使用SELECT TOP 10/1 PERCENT來限制返回的記錄數，使用SET ROWCOUNT來限制操作的記錄數，避免整表掃描。返回不必要的數據，不但浪費了伺服器的I/O資源，加重了網路的負擔，如果表很大的話，在表掃描期間將表鎖住，禁止其他的聯接訪問，後過很嚴重的。（3） SQL的注釋申明對執行查詢輸出沒有任何影響。（4） 使用計算列對數據進行簡單計算，盡量避免在查詢語句中對數據進行運算。（5） 盡可能不使用游標，它會佔用大量的資源。如果需要ROW-BY-ROW地執行，盡量採用非游標技術，如：客戶端循環、臨時表、TABLE變數、子查詢、CASE語句等等。（6） 使用PROFILER來跟蹤查詢，得到查詢所需的時間，找出SQL的問題所在，用索引優化器優化索引。（7） 注意UNION和UNION ALL的區別。在沒有必要的時候不要用DISINCT，它同UNION一樣會降低查詢速度，重復的記錄在查詢里是沒有問題的。（8） 用sp_configure 『query governor cost limit』或者 SET QUERY_COVERNOR_COST_LIMIT來限制查詢消耗的資源。當評估查詢消耗的 資源超出限制時，伺服器自動取消查詢，在查詢之前就扼殺掉。SET LOCKTIME 設置鎖的時間。（9） 不要在WHERE子句中列名加函數，如CONVERT，SUBSTRING等，如果必須用函數的時候，創建計算列在創建索引來替代。NOT IN會多次掃描表，使用EXISTS、NOT EXISTS、IN、LEFT OUTER JOIN來替代，其中EXISTS比IN更快，最慢的NOT操作。（10） 使用QUERY ANALYZER，查看SQL語句的查詢計劃和評估分析是否是優化的SQL。一般20%的代碼佔用了80%的資源，優化的重點就是這些慢的地方。（11） 如果使用了IN或者OR等時發現查詢沒有走索引，使用顯式申明指定索引，如：Select * From FA01(INDEX=IX_SEX) Where AA0107 IN(『01』,『02』)。（12） 在需要對已有數據進行比較復雜計算才能獲得查詢的結果數據時,將需要查詢的結果預先計算好放在表中,查詢的時候在SELECT。（13） 資料庫有一個原則是代碼離數據越近越好，所有有限選擇DEFAULT，依次為RULES，CONSTRAINT，PROCEDURE來編寫程序的質量高，速度快。如果要插入大的二進制到IMAGE列，使用存儲過程，千萬不要用內嵌INSERT直接插入。因為這樣應用程序首先將二進制轉換成字元串，伺服器收到字元後又將他轉換成二進制。存儲過程直接傳入二進制參數即可，處理速度明顯改善，如：CREATE PROCEDURE image_insert @image varbinary as Insert into table(fImage) values(@image)。（14） Between在某些時候比IN速度更快，更快地根據索引找到范圍。由於IN會比較多次，所以有時會慢些。（15） 盡量不要建沒有作用的事務例如產生報表時，浪費資源，只有在必須使用事務時才建立合適的事務。（16） 用OR的字句可以分解成多個查詢，並通過UNION連接多個查詢。速度取決與是否使用索引。如果查詢需要用聯合索引，用UNION ALL執行的效率更高些。（17） 盡量少用視圖，視圖的效率低。對視圖操作比直接對表操作慢，可以用SRORED PROCEDURE來代替。特別是不要用視圖嵌套，嵌套視圖增加了尋找原始資料的難度。視圖是存放在伺服器上的被優化好了的已經產生查詢規劃的SQL。對單表數據檢索時，不要使用指向多表的視圖，否則增加了不必要的系統開銷，查詢也會受到干擾。沒有必要時不要用DISTINCT和ORDER BY，這些動作可以改在客戶端執行，增加了額外的開銷，這同UNION和UNION ALL原理相同。（18） 當使用SELECT INTO和CREATE TABLE時，會鎖住系統表（SYSOBJECTS，SYSINDEXES等），從而阻塞其他的連接的存取。所以千萬不要在事務內部使用。如果經常要用到臨時表時請使用實表或者臨時表變數。盡量少用臨時表，用結果集和TABLE類型的變數來代替。（19） 在使用GROUP BY HAVING子句時，在使用前剔除多餘的行，盡量避免使用HAVING子句剔除行工作。剔除行最優的執行順序是：SELECT的WHERE子句選擇所有合適的行，GROUP
G. SQL Server 優化存儲過程的方法有哪些
優化存儲過程有很多種方法，下面介紹最常用的7種。
1.使用SET NOCOUNT ON選項
我們使用SELECT語句時，除了返回對應的結果集外，還會返回相應的影響行數。使用SET NOCOUNT ON後，除了數據集就不會返回額外的信息了，減小網路流量。
2.使用確定的Schema
在使用表，存儲過程，函數等等時，最好加上確定的Schema。這樣可以使SQL Server直接找到對應目標，避免去計劃緩存中搜索。而且搜索會導致編譯鎖定，最終影響性能。比如select * from dbo.TestTable比select * from TestTable要好。from TestTable會在當前Schema下搜索，如果沒有，再去dbo下面搜索，影響性能。而且如果你的表是csdn.TestTable的話，那麼select * from TestTable會直接報找不到表的錯誤。所以寫上具體的Schema也是一個好習慣。
3.自定義存儲過程不要以sp_開頭
因為以sp_開頭的存儲過程默認為系統存儲過程，所以首先會去master庫中找，然後在當前資料庫找。建議使用USP_或者其他標識開頭。
4.使用sp_executesql替代exec
原因在Inside Microsoft SQL Server 2005 T-SQL Programming書中的第四章Dynamic SQL裡面有具體描述。這里只是簡單說明一下：sp_executesql可以使用參數化，從而可以重用執行計劃。exec就是純拼SQL語句。
5.少使用游標
可以參考Inside Microsoft SQL Server 2005 T-SQL Programming書中的第三章Cursors裡面有具體描述。總體來說，SQL是個集合語言，對於集合運算具有較高的性能，而Cursors是過程運算。比如對一個100萬行的數據進行查詢，游標需要讀表100萬次，而不使用游標只需要少量幾次讀取。
6.事務越短越好
SQL Server支持並發操作。如果事務過多過長，或是隔離級別過高，都會造成並發操作的阻塞，死鎖。此時現象是查詢極慢，同時cup佔用率極低。
7.使用try-catch來處理錯誤異常
SQL Server 2005及以上版本提供對try-catch的支持，語法為：
begin try
----your code
end try
begin catch
--error dispose
end catch
一般情況可以將try-catch同事務結合在一起使用。
begin try
begin tran
--select
--update
--delete
--…………
commit
end try
begin catch
--if error
rollback
end catch
====================== 分割線 =======================
『自己的一些調優經驗』
1. 少使用游標是個很好的建議，為此，我自己也遇到過一些事故，是游標所造成的，由於，游標是逐行逐行操作的，當記錄較多時，經常會遇到超時的情況。
2. 多表join做查詢時，查詢的欄位盡量不要使用case when then else end的語法，或者使用用戶函數，例如：
select (case when fType=1 then '是' else '否' end) as fTypeName, dbo.F_GetFullName(fID) as fFullName from Table1 inner join Table2……
當兩個表的數據量非常大時，你可以在查詢分析器中明顯感覺到：直接查詢fType和fID與查詢上面兩個欄位的速度，很可能使用了一個case when then就導致超時。
針對這種情況，可以分兩種做法：
第一，把一些簡單的轉換可以放在程序中完成。
第二，如果需要通過ID查詢全名或者全稱，類似的，可以創建好視圖，直接查視圖，或者，先把所有的fFullName查出來放到臨時表中，直接join臨時表（如果這個數據不是很多的話），獲得fFullName。
3. 少使用一些嵌套的查詢，用臨時表緩存中間數據，例如：
select * from Table1
inner join (
select count(1) as count, Table2.ID2 from Table2 inner join Table3 on ID2=ID3 group by Table2.ID2
) as t1 on t1.ID1 = Table1.ID1
我曾經遇到這樣情況，上面的語句是那種情況的簡化版本，把其他不影響結果的表格都去掉了，發現一個奇怪的現象：嵌套查詢的結果集並不大，大約就200多行，Table1有6w條記錄，結果，這個查詢語句超時，查詢分析器中執行2分鍾也得不到結果。
後來，這樣一改，就Ok了，3秒出結果：
select count(1) as count, Table2.ID2 into #temp from Table2 inner join Table3 on ID2=ID3 group by Table2.ID2
select * from Table1
inner join #temp as t1 on t1.ID1 = Table1.ID1
這樣一改，效率提升了幾十倍，猜想：可能是嵌套的查詢是動態的，每一行的join可能都需要先執行嵌套的查詢，從而導致效率極差。
所以，如果查詢足夠復雜，join多個表，需要連接多個通過group by求和、求平均數等運算計算出來的中間數據，那麼，不妨多使用臨時表緩存中間數據。
4. 還有一些是必須遵守的一些默認規則，比如：
先過濾後連接。
查詢的欄位最要不要用「*」，指定需要用的欄位，減少網路流量。
『總結』
對於性能的追求是沒有極限的，做到你所能做到的，這是一個很好的習慣。
有些業務邏輯放在存儲過程中處理比較方便，而有些業務邏輯交給程序來處理，同樣會提升系統整體的效率，看實際情況而定。
總之，盡可能減少這些容易引發性能問題的隱患，系統就會跑得更穩定更有效率，一切從小細節做起。
H. SQLServer2005性能監測與優化的介紹
《SQL Server2005性能監測與優化》由袁鵬飛 鍾發英 馬娜 所著，本書從資料庫的基本工作原理入手，系統介紹了SQL Server資料庫體系結構、索引優化、SQL語句優化、性能優化工具、系統存儲過程、系統表、系統視圖、分區技術、死鎖處理等，最後幫助讀者設計實現兩個資料庫性能分析和監測工具
I. 如何優化sql server 伺服器性能
你可以通過profiler和性能工具，跟蹤一段時間，然後分析一個瓶頸是什麼，再對瓶頸進行處理。
一般來說，增加足夠大的內存能讓性能快速提高。
使用更快的硬碟。
把資料庫分離業務，比如A業務訪問A資料庫，B業務訪問B資料庫。
J. 怎麼用SQL語句去優化資料庫是SQLserver2005
通常情況下,即在資料庫的數據量,伺服器硬體都在承受范圍內,進行的是:
1.語句調優,包括創建索引,優化語句的實現方式使執行計劃更流暢
2.表結構變更,即在語句級別的調優沒有辦法滿足性能要求的時候不得不採用的措施.包括表的拆分,橫向拆分,縱向拆分等
還有其他的一些比較大的改動,包括伺服器遷移,讀寫分離,分布式規劃等等