對於優化sql語句或儲存過程，以前主要是用如下語句來判斷具體執行時間，但是sql環境是複雜多變的，下面語句並不能精準判斷效能是否提高；如果需要精確知道cpu、io等資訊，就無能為力了。
convert(varchar(30),getdate(),121
)select
*from sales.salesorderdetail where salesorderid >
64185
convert(varchar(30),getdate(),121)
這時候如果使用set statistics time on和set statistics io on指令就能清楚的知道了，在測試之前需執行下面2條命令
dbcc dropcleanbuffers清除緩衝區
dbcc freeproccache刪除計畫快取記憶體中的元素
-- 測試
首先執行下面指令碼
--開啟統計資訊
setstatistics time on
setstatistics io on
goselect
*from sales.salesorderdetail where salesorderid >
64185
go
結果如下
--1. cpu 時間
=0 毫秒，占用時間 =
53毫秒。
--2.
cpu 時間
=0 毫秒，占用時間 =
0毫秒。 (
35292
行受影響)
--3.
表 'salesorderdetail
'。掃瞄計數 1，邏輯讀取 337 次，物理讀取 4 次，預讀 333 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0次。
--4.
cpu 時間
=47 毫秒，占用時間 =
893 毫秒。
說明：標記1：表示將語句的結果放到sql緩衝區所需要的cpu時間和總時間
標記2：標識從緩衝區中取出解析結果所需要的時間
標記4：標識這次查詢使用了多少cpu時間和總的時間，其中cpu時間是對查詢所需cpu資源的一種比較穩定的測量方式；總時間則跟sql伺服器有關，因此比較不穩定；所以效能判斷的時候可以以cpu時間來做標準。
標記3：資源時間；其中邏輯讀是指sql從緩衝區讀取的資料；物理讀是指從資料從磁碟讀取到緩衝區中；
再次執行查詢語句結果如下，由於第一次執行的時候，資料已經從磁碟讀取到緩衝區，因此標記1的時間也就是0了，標記3物理讀也為0了。
--1. cpu 時間
=0 毫秒，占用時間 =
0毫秒。
--2.
cpu 時間
=0 毫秒，占用時間 =
0毫秒。 (
35292
行受影響)
--3.
表 'salesorderdetail
'。掃瞄計數 1，邏輯讀取 337 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0次。
--4.
cpu 時間
=32 毫秒，占用時間 =
848 毫秒。
在優化sql語句的時候可以從cpu時間，邏輯讀取數來判斷效能是否提公升，而且這2個指標是比較真實的反映了sql執**況的。這裡只是簡單介紹了一下這2個命令的一些基本資訊，則需更加深入了解sql底層知識。
資料庫效能優化
資料庫設計 實現sql server資料庫的優化，首先要有乙個好的資料庫設計方案。在實際工作中，許多sql server方案往往是由於資料庫設計得不好導致效能很差。實現良好的資料庫設計必須考慮這些問題 1.邏輯資料庫規範化問題 一般來說，邏輯資料庫設計會滿足規範化的前3級標準 第1規範 沒有重複的組...
資料庫效能優化
1 系統設計 1 縱向 橫向分割表，減少表的尺寸 縱向 欄位多。按業務主題分割。根據頁大小。橫向 資料多。按條件分割表。eg 按年儲存表，歷史資料表和當期資料更新表。2 將資料處理交給db，編寫儲存過程 1 減少網路的開銷 2 儲存過程是編譯 優化過，速度快。3 唯讀查詢操作優化方法 1 資料量小的...
資料庫效能優化
最近要寫一些關於企業級應用的優化內容的東西，就先從資料庫優化入手吧，在這裡先記錄一下。作為一名有資料庫教育背景的工作人員，我著重從db的角度介紹一下，我認為的db優化方式。首先，撇開經濟商業用處不談，db效能優化的原則主要是，通過盡可能少的磁碟訪問獲得所需的資料。一般而言，資料的是優化可以從三方面分...