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。設定主動縮短日誌。關於大的資料庫不要設定資料庫主動新增，它會下降伺服器的功用。#p#
在T-SQL的寫法上有很大的考究，下面列出常見的關鍵：首要，DBMS處理查詢方案的程式是這樣的：
1、查詢句子的詞法、語法檢查
2、將句子提交給DBMS的查詢最佳化器
3、最佳化器做代數最佳化和存取途徑的最佳化
4、由預編譯模組生成查詢規劃
5、然後在適宜的時刻提交給體系處理履行
6、***將履行成果回來給使用者。
其次，看一下SQL SERVER的資料寄存的結構：一個頁面的鉅細為8K(8060)位元組，8個頁面為一個盤區，依照B樹寄存。
12、Commit和rollback的差異Rollback：回滾一切的事物。Commit：提交當時的事物。沒有必要在動態SQL裡寫事物，假如要寫請寫在外面如：begin tran exec(@s) commit trans或許將動態SQL寫成函式或許儲存程式。
13、在查詢Select句子頂用Where字句束縛回來的行數,防止表掃描,假如回來不用要的資料，浪費了伺服器的I/O資源，加劇了網路的擔負下降功用。假如表很大，在表掃描的期間將表鎖住，制止其他的聯接拜訪表,後果嚴重。
14、SQL的註釋宣告對履行沒有任何影響
15、儘可能不運用游標，它佔用很多的資源。假如需求row-by-row地履行，儘量選用非游標技能，如：在客戶端迴圈，用暫時表，Table變數，用子查詢，用Case句子等等。
遊標可以依照它所支撐的提取選項進行分類：只進有必要依照從行到一行的次序提取行。FETCH NEXT是僅有答應的提取操作，也是默許辦法。可翻滾功用夠在遊標中任何當地隨機提取恣意行。遊標的技能在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提示將使指定了該提示的表在遊標內是隻讀的。
16、用Profiler來盯梢查詢，得到查詢所需的時刻，找出SQL的問題所在;用索引最佳化器最佳化索引
17、留意UNion和UNion all 的差異。UNION all好
18、留意運用DISTINCT，在沒有必要時不要用，它同UNION相同會使查詢變慢。重複的記錄在查詢裡是沒有問題的
19、查詢時不要回來不需求的行、列
20、用sp_configure ‘query governor cost limit’或許SET QUERY_GOVERNOR_COST_LIMIT來束縛查詢耗費的資源。當評價查詢耗費的資源超出束縛時，伺服器主動撤銷查詢,在查詢之前就扼殺掉。SET LOCKTIME設定鎖的時刻
21、用select top 100/10 Percent來束縛使用者回來的行數或許SET ROWCOUNT來束縛操作的行
22、在SQL2000曾經，一般不要用如下的字句: “IS NULL”, “”, “!=”, “!>”, “!
本作品採用《CC 協議》，轉載必須註明作者和本文連結