sqlserver中幾種典型的等待

在最近的幾次sqlserver問題的排查中，總結了sqlserver幾種典型的等待類型，類似於oracle中的等待事件，如果看到這樣的等待類型時候能夠迅速定位問題的根源,下面通過一則案例來把這些典型的等待處理方法整理出來

為了准備今年的雙11很久沒有更新blog，在最近的幾次sqlserver問題的排查中，總結了sqlserver幾種典型的等待類型，類似於oracle中的等待事件，如果看到這樣的等待類型時候能夠迅速定位問題的根源,下面通過一則案例來把這些典型的等待處理方法整理出來：

第一種等待.memory等待

早上接到一用戶反饋其RDS實例非常的慢，通過觀察sqlserver活動會話監視器（active monitor）的waiting tasks（類似於mysql的thread running）可以看到有10多w的等待任務,可以明確數據庫現在已經出現了較大的瓶頸，緊接著通過resource waits看到數據庫中有大量的memory內存等待：

看到是memory 資源等待後，為了立刻恢復用戶應用，想到立刻去調大內存，發現該實例已經是24G了，看來一下os的空余內存，還有較多的內存剩余，所以將內存調大到36G，發現resource waits還是在memory上等待，同時這個時候的cpu使用率飙升，達到了90%左右（之前在10%左右的等待）.這樣解決不了根本問題，於是通過recent expensive queries,發現以下sql的邏輯讀很高，執行非常頻繁：

SELECT * FROM RefundOrder_Message messages0_ WHERE messages0_.Order_Id=@p0;

也可以通過如下方式獲得造成內存等待的sql：
SELECT st.text FROM sys.dm_exec_query_memory_grants req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as ST where req.grant_time is NULL or req.granted_memory_kb is NULL

The columns grant_time and granted_memory_kb will be NULL for those queries which are waiting to get their requested memory

sp_helpindex RefundOrder_Message
發現該表只有一個主鍵索引：

創建一下索引：
create index ind_RefundOrder_Message_order_id on RefundOrder_Message(Order_Id);

第二種等待：latch等待

在索引加上去後，memory的等待立刻消失，但是resource waits的等待變為了 lock：

通過以下內部視圖可以發現如下調用出現了等待：
SELECT ss.host_name, req.blocking_session_id,req.wait_type ,req.wait_time ,req.wait_resource ,req.transaction_id ,st.text FROM sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as ST
cross apply sys.dm_exec_sessions ss where req.status =N'suspended' and ss.session_id=req.session_id;

得到阻塞其他會話的sql：
(@p0 int,@p1 nvarchar(4000),@p2 bit)
SELECT TOP (@p0) this.* FROM ViewSalesOrder this_ WHERE this_.MemberCode = @p1 and this_.IsObsolete = @p2 ORDER BY this_.OdCode desc;

視圖ViewSalesOrder是一張非常核心的視圖，裡面關聯了訂單，訂單消息，訂單發貨等多個業務邏輯；查詢條件中代入了membercode為店鋪的名稱，可能操作某個店鋪的訂單；
通過ViewSalesOrder視圖中的定義，membercode，IsObsolete ，OdCode 為salesOrder表的三個字段，查看salesOrder上並沒有相應的索引，於是加上如下索引：
create index ind_salesOrder_member on salesOrder(membercode,IsObsolete,code)；
在添加完索引後，數據庫的waiting tasks 下降，batch requests提升：

第三種等待：lock

第三種等待是常見的等待，常見的情況在刪除，更新的時候由於條件中沒有合適的索引導致鎖定的記錄范圍太大，導致阻塞其他的會話請求：

用戶在在進行壓測的時候發現一條更新語句執行的非常慢，導致整個系統都卡住：

update DD_ShenHe   set ZF = 0   where zf is null;

查看dd_shenhe表上面的索引：

可以看到表中並沒有zf字段的索引，而該表總共有400w的數據，zf 為null的有8000條，所以在zf字段添加索引是合適的：

Create index ind_dd_shenhe_zf on dd_shenhe(zf);

添加完索引後，系統恢復正常。