對單錶超過300w+資料的web應用程式進行測試後發現了一些功能、效能問題，採取了以下辦法來進行調整：
將絕大部分的sql查詢改為儲存過程，這樣的操作毫無疑問可以提高部分效能。
凡是使用「select * from ***」的操作一律具體到所需欄位。
使用join連線2個以上大量資料的表，且基礎資料表變化不大的查詢一律使用檢視，並為此檢視建立索引。理由來自sql server聯機幫助手冊：
「對於標準檢視而言，為每個引用檢視的查詢動態生成結果集的開銷很大，特別是對於那些涉及對大量行進行複雜處理(如聚合大量資料或聯接許多行)的檢視。如果在查詢中頻繁地引用這類檢視，可通過對檢視建立唯一聚集索引來提高效能。對檢視建立唯一聚集索引後，結果集將儲存在資料庫中，就像帶有聚集索引的表一樣。
對檢視建立索引的另乙個好處是：優化器可以在未直接在 from 子句中指定某一檢視的查詢中使用該檢視的索引。這樣一來，可從索引檢視檢索資料而無需重新編碼，由此帶來的高效率也使現有查詢獲益。」
凡是使用 "select count(*) from ***" 或是"select count(id) from ***」(此處id為主鍵)的查詢，一律改為」select count(1) from ***」，理論上採用*來做聚合值，sql server會自動尋覓最合適的字段以進行聚合，但這樣仍然會占用系統開銷，即使主鍵也沒有1來得快。
對於多條件的組合查詢，我們一般會寫成」where ((@condition is null) or (condition=@condition))」形式的儲存過程條件來進行查詢，但這樣的操作會因為」is null 」導致效能問題，反覆實地檢測後採用了」where 1 = 1 」，然後根據條件「if @condition is not null set @sqltext=@sqltext+' and condition=''' + @condition +''''，最後 「exec sp_executesql @sqltext」 的方式，這樣確實可帶來明顯的效能提公升，分析應是」is null 」或」is not null」導致了索引失效，進行了全表掃瞄。
對使用row_number()函式的表建立合適的索引，必須要有最合適的索引才能避免重建索引時的全表row_number()運算帶來的效能問題，而且索引的方向也很重要，比如時間類的索引用降序往往比公升序效能高。
這個不是效能問題，但也很重要，在儲存過程中應使用scope_identity()函式來獲得最新的標量，而不是@@identity這個全域性變數，因為@@identity會受到觸發器的影響而失去正確值。
原文出處：
資料庫效能測試
資料庫壓力測試的原理與web測試的原理應該是一致的，都是通過jmeter多執行緒的機制模擬壓力來測試資料庫的處理能力。1 新增oracle資料庫驅動 2 新增執行緒組 3 新增jdbc connection configuration 4 新增jdbc request 配置解析 sql query ...
JMeter資料庫效能測試
如何使用jmeter來進行資料庫效能測試呢？初學jmeter的測試人員可能會十分感興趣，其實直連的mysql進行效能測試十分簡單，接下來就進入到jmeter資料庫效能測試 本地資料庫的測試之旅。一 jmeter建立資料庫測試計畫 假設建立10個併發使用者，而每個併發使用者會傳送兩個sql請求到資料庫...
資料庫效能優化測試
對於優化sql語句或儲存過程，以前主要是用如下語句來判斷具體執行時間，但是sql環境是複雜多變的，下面語句並不能精準判斷效能是否提高 如果需要精確知道cpu io等資訊，就無能為力了。print convert varchar 30 getdate 121 select from sales.sal...