set showplan on 查詢計畫資訊
set statistics io on
set statistics time on
set noexec on 編譯不執行
set fmtonly on 資料庫在接收到客戶端對資料的請求之後，直接從系統表中獲取資料列資訊，生成空的結果集直接返回客戶端，而不再對磁碟中儲存的資料進行檢索處理。
先設定set fmtonly on，再設定set showplan on，編譯不執行可以看到查詢計畫資訊。但若開啟set statistics io on，set statistics time on看不出相關資訊，值都為0。
set forceplan on 強迫查詢按照from子句中指定的順序使用表。
set table count 10 優化器優化時連線涉及表的張數，增加table count意味著編譯時間也會增加，因為優化器會用更的時間評價各種連線混合體。
sp_cachestrategy 設定狀態bit來開啟或者關閉預取和獲取-丟棄快取策略。
sp_cachestrategy db_name, table_name, index_name
sp_cachestrategy db_name, table_name, "table only", mru, "on"
sp_cachestrategy db_name, table_name, "table only", prefetch, "on"
set paralle1_degree 10 設定能夠用於查詢的併發執行的工作程序最大數目。譔值<=最大併發度配置引數值。
dbcc traceon(302，301)
執行set statistics io on
set statistics time on
後，執行關聯查詢獲得查詢統計資訊如下：
parse and compile time 0.
sql server cpu time: 0 ms.
table: table1 scan count 1, logical reads: (regular=1 apf=0 total=1), physical reads: (regular=0 apf=0 total=0), apf ios used=0
table: table2 scan count 238, logical reads: (regular=27 apf=0 total=27), physical reads: (regular=0 apf=0 total=0), apf ios used=0
total writes for this command: 0
execution time 0.
sql server cpu time: 0 ms. sql server elapsed time: 0 ms.
(1 row affected)
引數說明：
logical reads：
regular 在快取記憶體中找到查詢所需的某頁的次數；在此只對非由非同步預取 (apf) 引入的頁進行計數。
apf 在快取記憶體中找到由 apf 請求所引入的某請求的次數
total regular 和 apf 邏輯讀取數的總和
physical reads：
regular 通過常規非同步 i/o 將緩衝區引入快取記憶體的次數
apf 由 apf 將緩衝區引入快取記憶體的次數
total regular 和 apf 物理讀取數的總和
apf ios used 由 apf 引入的緩衝區數，在查詢過程中會用到這些緩衝區中的一頁或多頁
掃瞄計數(scan count)：在查詢中涉及到的表被訪問的次數。在我們的例子中，其中的表只被訪問了1次，由於查詢中不包括連線命令，這一資訊並不是十分有用，但如果查詢中包含有乙個或多個連線，則這一資訊是十分有用的。（乙個迴圈外部的表的scan count值為1，但對於乙個迴圈內的表而言，其值為迴圈的次數。可以想象得到，對於乙個迴圈內的表而言，其scan count值越小，它所使用的資源越少，查詢的效能也就越高。因此在調節乙個帶連線的查詢的效能時，需要關注scan count的值，在進行調節時，注意觀察它是增加還是減少了。）
邏輯讀取(logical reads)：這是set statistics io或set statistics time命令提供的最有用的 資料。我們知道，資料庫在可以對任何資料進行操作前，必須首先把資料讀取到其資料緩衝區中。此外，我們也知道資料庫何時會從資料緩衝區中讀取資料，並把資料讀取到大小為8k位元組的頁中。那麼logical reads的意義是什麼呢？logical reads是指資料庫為得到查詢中的結果而必須從資料緩衝區讀取的頁數。在執行查詢時，資料庫不會讀取比實際需求多或少的資料，因此，當在相同的資料集上執行同乙個查詢，得到的logical reads的數字總是相同的。（資料庫執行查詢時的logical reads值每一次這個數值是不會變化的。因此，在進行查詢效能的調節時，這是乙個可以用來衡量你的調節措施是否成功的乙個很好的標準。如果 logical reads值下降，就表明查詢使用的伺服器資源減少，查詢的效能有所提高。如果logical reads值增加，則表示調節措施降低了查詢的效能。在其他條件不變的情況下，乙個查詢使用的邏輯讀越少，其效率就越高，查詢的速度就越快。）
物理讀取(physical reads)：物理讀，在執行真正的查詢操作前，資料庫必須從磁碟上向資料緩衝區中讀取它所需要的資料。在資料庫開始執行查詢前，它要作的第一件事就是檢查它所需要的資料是否在資料緩衝區中，如果在，就從中讀取，如果不在，資料庫必須首先將它需要的資料從磁碟上讀到資料緩衝區中。我們可以想象得到，資料庫在執行物理讀時比執行邏輯讀需要更多的伺服器資源。因此，在理想情況下，我們應當盡量避免物理讀操作。下面的這一部分聽起來讓人容易感到糊塗 了。在對查詢的效能進行調節時，可以忽略物理讀而只專注於邏輯讀。你一定會納悶兒，剛才不是還說物理讀比邏輯讀需要更多的伺服器資源嗎？情況確實是這樣， 資料庫在執行查詢時所需要的物理讀次數不可能通過效能調節而減少的。減少物理讀的次數是dba的一項重要工作，但它涉及到整個伺服器效能的調節，而 不僅僅是查詢效能的調節。在進行查詢效能調節時，我們不能控制資料緩衝區的大小或伺服器的忙碌程度以及完成查詢所需要的資料是在資料緩衝區中還是在磁碟 上，唯一我們能夠控制的資料是得到查詢結果所需要執行的邏輯讀的次數。
因此，在查詢效能的調節中，我們可以心安理得地不理會set statistics io命令提供的physical read的值。（減少物理讀次數、加快資料庫執行速度的一種方式是確保伺服器的物理記憶體足夠多。）
一般在資料庫的查詢優化過程中，logic read是至關重要的，它的計數一般與查詢出來的結果集數量成正比，與資料讀取的速度也成正比。因此，我們便可以從中看出整個查詢（複雜語句，包括儲存過程等）中的瓶頸所在，從而進行優化。
sybase效能調優命令收集
sybase效能調優 1 修改之前 sp configure 儲存資訊 2 sp configure lock scheme 檢視當前伺服器預設鎖模式 3 sp configure lock scheme 0,datarows 修改預設級別為資料行鎖 4 sp help tab name或sp he...
sybase的SQL多表聯合查詢調優
sybase的sql多表聯合查詢調優 摘要 在大型專案中關係型資料庫多表聯合查詢是很頻繁的，現在專案上有以下7張表，每張表達資料量也比較小，但是7張表通過多表聯合查詢，查詢的速度卻非常慢，希望能夠給出乙個查詢效率比較快的sql。表1 oper，欄位id，operkey等等 資料量3500 表2 po...
查詢效率調優
使用者報說統計查詢慢，在頁面嘗試了下，統計兩個月的資料大約需要5秒，把那段執行的sql，直接通過toad連線到資料庫中嘗試，1秒不到。初始以為是 問題或者是jdbc驅動等問題，後來嘗試應用連線不同資料庫，結果如下 開發資料庫 資料總數2181377條，首次1100ms，後面平均查詢速度719ms 測...