2、      您認為在T-SQL編寫（包括儲存過程、函式和檢視）上，哪些因素會影響SQL Server效率?

討論彙總——索引使用

l  沒有索引或者沒有用到索引、I/O吞吐量小、沒有建立計算列導致查詢不優化、鎖或者死鎖、查詢語句不夠優化等

l  對大表而言。那些不走索引的語句，錯誤scan的語句，還有那些強制使用HINT的語句，可能會因為時間的推移，影響了SQL Server對最優計劃的生成

l  避免無法使用索引的過濾條件。如 WHERE dbo.ufn.Test(ID)=1

l  確保存在適合查詢的索引

l  根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的資料量。注意填充因子要適當（最好是使用預設值

l  如果是使用like進行查詢的話，簡單的使用index是不行的，但是全文索引，耗空間。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時，查詢耗時和欄位值總長度成正比,所以不能用CHAR型別，而是VARCHAR。對於欄位的值很長的建全文索引

討論彙總——遊標：

l  遊標的頻繁 "開 / 關", 既消耗資源, 同時會給相關的表加"鎖"

l  可以通過集合運算的方式去處理資料的情況下，避免使用遊標

l  儲存過程通過遊標的方式，將函式的功能放在了遊標的計算中，這樣速度有了一些提高

l  考慮將遊標用其他方式改寫（需要驗證方法是否有效，無法保證效能的改寫，可能比直接使用遊標更糟糕），或確保遊標高效

l  個人補充：

a）  對於必須逐行處理的情況，建議直接使用遊標，如果要避免對構成遊標來源資料的影響，可以考慮使用靜態遊標。對於可以使用集合處理模式替代洲標的情況，也要考慮替代之後的查詢複雜性和涉及的資料量，如果這個修改產生的查詢非常複雜或涉及大量資料，那麼用遊標可能可以得到更佳或者更穩定的效果，建議通過測試驗證決定最終的方案

b）  注意遊標型別的選擇

c）  經常使用遊標片大量資料量，考慮適當調整cursor threshold選項（非同步生成控制）

討論彙總——臨時表與表變數

l  表變數和臨時表的使用要有規定，大小也要有個估計

l  臨時表和記憶體表要分別對待

l  個人補充：表變數不受事務控制，其資料寫入效率比臨時表高；但

討論彙總——綜合

l  儲存過程、檢視、函式的一個好處是查詢計劃重用（預先編譯)），但還是要注意會導致重編譯的操作，例如儲存過程中引用和臨時表、檢視結構更改等

l  使用不合適的資料型別, 如與表字段不一致, 或發生隱式轉換 (字元轉數字)

l  SET NOCOUNT ON , 避免DML操作不必要的網路傳輸

l  最典型的函式加於欄位上再判斷。不正確的實現邏輯將導致效能問題。。當然，這本不屬於DB平臺的事兒了，是實現者的事兒

l  編寫SQL語句時，在保證完成需要情況下儘量保證SQL簡單易讀，導致效率抵消的原因有：

a）  過大的事務操作導致事務之間嚴重阻塞

b）  返回過多無用資料引發磁碟和網路壓力

c）  過多的非集合化操作，如在返回列頻繁呼叫某個函式

d）  查詢中使用負邏輯

e）  不必要的排序,，查詢不需要的資料

f）  冗餘的判斷邏輯,，多層檢視的巢狀引用.

l  檢查不良的SQL，考慮其寫法是否還有可優化內容

a）  檢查子查詢。考慮SQL子查詢是否可以用簡單連線的方式進行重新書寫

b）  考慮資料庫的優化器

c）  儘量避免大事務操作, 提高系統併發能力

d）  儘量避免向客戶端返回大資料量, 如採用分頁

e）  儘量避免遊標使用進行大規模資料的連線和遍歷

l  資料庫引擎的本身的優化。每個資料庫的查詢引擎也是在不斷進化當中的，有些以前高效的語句現在顯得落伍了

l  .資料庫設計優化：在針對不同主題，不同分析方向的時候資料本身的設計結構也會使得SQL語句的寫法有所不同

l  70%效能問題出自不良的SQL語句。條件不符合SAR規範，遊標濫用，事務過長，複雜業務邏輯實現追求功能，不考慮效能等等

l  避免大表的distinct

l  T-SQL編寫要對複雜度進行規定，不能無限制的巢狀或者Union等等。T-SQL中檢索資料規模也需要估計

l  在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的資料，浪費了伺服器的I/O資源，加重了網路的負擔降低效能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。

l  儲存過程要設計合理，當然提示資料庫效率，主要在表的結構和使用合理的查詢方法

l  檢視的資料要放在記憶體中執行，這樣才能提升效率，但是要加記憶體

l  join的時候要命中index，少用多層巢狀，可以考慮用臨時表

l  設計SQL後，應使用explain命令檢查SQL，看是否使用到索引，是否存在filesort,重點檢查檢索的行數（rows）是否太大。一般來說.：

a）  rows<1000，是在可接受的範圍內的。

b）  ows在1000~1w之間，在密集訪問時可能導致效能問題，但如果不是太頻繁的訪問（頻率低於1分鐘一次），又難再優化的話，可以接受，但需要注意觀察

c）  rows大於1萬時，應慎重考慮SQL的設計，優化SQL，優化db，一般來說不允許頻繁執行（頻率低於1小時一次）

d）  rows達到10w級別時，堅決不能做為實時執行的SQL。但導資料場合除外，但導資料必須控制好時間，頻度

l  在設計SQL，尤其是稍微複雜的SQL時，一定要在測試環境甚至是實際環境上預先進行explain

l  ＳＱＬ語句避免不符合ＳＡＲＳ條件的

l  遊標和觸發器儘量避免使用

l  避免長事務，避免出現阻塞和死鎖　

l  複雜邏輯可以多次實現

l  動態拼接SQL語句是影響SQLServer效率的一個方面

l  儲存過程中多表的連線查詢也是影響SQL Server效率的一個方面，當然是許多資料庫都具備的毛病，大概是CBO生成執行計劃不佳的一個問題，迫不得已多使用臨時表

l  應該採用函式或儲存過程代替複雜的檢視，效能更好

個人補充：使用自定義函式的時候要注意評估。返回單個值的函式最好能夠保障是確定性函式；查詢優化器不會為多語句表值函式建立統計資訊，所以如果多語句表值函式是用於關聯查詢的話，可能會產生較差的查詢方案

l  SQL Server沒有oracle的非阻塞讀，不光是寫/寫，讀/寫也會有衝突，應該勁量避免，比如：使用短小事務，合理設定並使用索引，如果可以的話做讀寫分離；影響SQL瓶頸的因素有很多，包括記憶體不足，硬體不行，或者沒有足夠的記憶體供SQL Server 使用，缺少有用的索引等，網路通訊不好，磁碟配置了，如tempdb 的配置，是否為查詢優化器提供了優化複雜查詢的最有利條件

個人補充：讀寫衝突，可以通過控制事務隔離級別（或者相關的表提示）來控制

l  .資料的量級：在資料量低大的情況下高效率的SQL語句在資料量高的情況下就不能用了，反之亦然

個人補充：T-SQL執行包括編譯（查詢方案評估選擇）和執行兩個步驟，在查詢方案選擇的步驟，查詢優化器可以根據統計資訊、物件結構評估出有效的查詢方案，當然，如果查詢過於複雜，或者是查詢成本評估所需要的資訊不準確，評估的結果也會存在誤差，所以大部分情況下不會出現需要根據資料量隨時調整查詢的情況

l  T-SQL方面SQL Server缺乏Oracle完備的分析函式支援功能，也缺乏一些行列轉換、樹形目錄結構方面的函式，雖然可以通過遞迴cte、xml等函式解決

個人補充：內建函式的多少無法對比，每個資料庫都有自己的一些考慮，但常用的基本上是不缺的，對於需要但確實沒有的，可以考慮自己寫CLR函式。行列轉換有 PIVOT 和 UNPIVOT；層次結構有 hierarchyid 資料型別和對應的一些函式

個人補充

l  複雜查詢是需要特別注意控制的。越複雜的查詢，意味著可選擇的查詢方案越多，查詢評估所涉及的方面越廣，這意味著查詢優化器評估查詢方案的成本越高，涉及的因素多，意味著評估的方案准確性越低。所以過於複雜的查詢，往意味著效能很難保障。瞭解SQL語句的處理過程，有助於理解這個問題（在聯機幫助中搜索“SQL 語句處理”）可以得到這方面的說明。另外，要特別注意兩種複雜查詢：

a）  很多個CTE定義組成的查詢。單看每個CTE定義，都很簡單，但最終組合起來的，很可能是一個很複雜的查詢，可以通過檢視執行計劃來確定。特別需要注意的是，通過CTE定義將執行步驟寫得再清晰和一目瞭然，最終執行也基本上不是按照寫的步驟去做的

b）  檢視（包括表值函式）巢狀導致的複雜查詢。查詢涉及的每個檢視可能很簡單，但一層層巢狀組合起來，可能最終也形成一個複雜查詢，這個也可以勇冠看執行計劃確定。（儘量避免在資料庫中使用模組化的設計思想）

l  注意實現方法的控制。比較常見的有下面這些：

a）  使用 JOIN 代替 EXISTS（包括IN）。這種很多時候容易出問題，特別是無法通過結構定義確定JOIN是否會產生一對多之類的情況下。EXISTS只需要考慮是否存在，JOIN還需要考慮資料是一對一，還是一對多或多對多，這兩者導致的查詢成本評估是不一樣的

b）  過多的 IN(值的列表)。這種基本上會被判斷為一堆的OR條件，而且會需要評估每個值，很多時候查詢成本是比較高的。可以考慮把值先放入臨時表，再IN 臨時表

c）  減少OR條件。不少的情況下，將OR條件改成多個 UNIONALL的結果會更高效一些

d）  注意條件和JOIN中的資料型別轉換。儘可能使用顯式的資料型別轉換，並將轉換的目標放在常量/變數/引數或者資料少的一方。隱式（自動）的資料型別轉換是根據型別優先順序確定轉換目標的，如果轉換操作發生在資料量大的一方，那查詢就會比較差了