查詢設計

13.1. 原則１——在小的結果集上操作

限制選擇列表中的列數

在select語句的選擇列表中使用最小的列集，不要使用輸出結果集中不需要的列。如不要使用select*，select*語句使覆蓋索引無效，并且也增加了網絡傳輸量。

使用高選擇性的Where子句

應該設計數據應用程序隨著用戶瀏覽數據而增量地請求數據。對于依靠大量數據進行分析或報告的應用程序，考慮使用數據分析解決方案如Analysis Services（分析服務）。

13.2. 原則2——有效使用索引

避免不可參數化的搜索條件

類型	搜索條件
不可參數化	<>、!=、!>、!<、NOT Exists、NOT IN、NOT Like IN、OR以及一些LIKE條件，如LIKE ‘%<literal>’
可參數化	=、>、>=、<、<=、Between以及一些LIKE條件，如LIKE ‘<literal>%’

?

避免Where子句列上的算術運算符

在Where子句中的列上使用算術運算符可以阻止優化器使用該列上的索引。

?

避免Where子句列上的函數

在Where子句中的列上使用函數可以阻止優化器使用該列上的索引。

13.3. 原則3——避免優化器提示

連接提示

提示阻止了自動參數化；阻止優化器動態決定表的連接范圍。

一般語法為：

select * from table ?option(LOOP JOIN)

select * from table ?option(MERGE JOIN)

select * from table ?option(HASH JOIN)

索引提示(即強制使用某個索引)

一般情況，讓優化器為查詢選擇最佳的索引策略，不要使用索引提示來忽略優化器的行為，而且不使用索引提示使優化器能夠動態地隨著數據的隨時變化而確定最佳的索引策略。

即一般不要用此語法：

select * from table where (index (indexName)) where condtion

13.4. 原則4——使用域和參照完整性

非空約束

定義非空列約束幫助優化器在查詢中該列上使用ISNULL函數時生成一個有效的處理策略。當不可避免地要處理Null值時，可以使用過濾索引來從索引中刪除NULL值，從而改進索引的性能。

?

聲明參照完整性

聲明參照完整性用于定義父表和子表之間的參照完整性，它確保子表中的記錄只當父表中存在對應記錄時存在。在SQLServer中DRI使用父表上的PRIMARY KEY和子表上的FOREIGN KEY約束實現。

?

域和參照完整性，它們不僅確保數據的完整性而且還改進性能，他們為優化器提供更多生成高成本效益執行計劃并改進性能的選擇。注意，子表上的外鍵列應該非空。

13.5. 原則5——避免資源密集型的查詢

避免數據類型轉換

當兩種不同的數據類型進行比較的時候，隱含數據類型將會自動起作用，但是它增加了查詢優化器的開銷。少數據的時候也許看不出來，但數據量較多的時候比較明顯。

?

使用exists代替count(*)來驗證數據的存在

使用count*驗證數據存在是高度資源密集型的，它必須掃描表中所有的數據。

?

使用UNION ALL代表UNION

如果允許最終結果集中有重復的列，使用UNION ALL避免了偵測和刪除重復的開銷，這將改進性能。

?

為聚合和排序操作使用索引

在order by/group by子句中引用的列上創建索引幫助優化器快速地組織結果集，因為在索引中列值被預先安排好。

?

避免批查詢中的局部變量

在批中的查詢的where子句使用局部變量(Declare)使優化器不能生成有效的執行計劃。不要使用局部變量作為批中的一個過濾條件，為批創建一個存儲過程。

如Declare @id int=1;

??select * from s>@id;

?

小心地命名存儲過程

不應該使用SP_開頭的存儲過程，帶有這個存儲過程開頭的名稱，SQL Server會自動判斷從master數據庫開始。

13.6. 原則6——減少網絡傳輸數量

將一組查詢作為批或存儲過程同時提交，可以減少網絡傳輸量，提高性能和管理。

?

SET NOCOUNT ON

<SQL queries>

SET NOCOUNT OFF

這樣將會去除掉服務器報告所影響的行數。也就是<Number> ?row(s) affected>的提示信息。

13.7. 原則7——減少事務開銷

減少日志開銷

?

如果每個查詢分別維護原子性，那么在事務日志磁盤上要進行較多的磁盤寫入操作以維護每個原子操作的持久性，而過多的磁盤活動將增加數據功能的執行時間。

?

DBCC SQLERF(Logspace)　顯示日志比例

?

減少日志磁盤寫操作數量的一個簡單方法是將操作查詢包含在一個明確的日志當中，最佳的方法是在事務中處理數據集而不是單行。（說白了就是一次最好能夠集中插入很多行）

如

begin transaction

SQL語句

commit

?

減少鎖請求的數量或降低鎖請求的時間，也將提高性能

默認情況下，SQL Server可以提供行級鎖，對于工作于大量行的查詢，在所有單獨的行上請求行鎖為鎖管理進程增加了很大的開銷，可以通過減小鎖的粒度來減少鎖開銷，比如使用頁面或者表級別的鎖。阻止select語句使用鎖也是一個辦法來降低鎖開銷。

總結

以上是生活随笔為你收集整理的漫游测试之性能测试(5.5-查询设计)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。