為了準備今年的雙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 [email protected];

也可以通過如下方式獲得造成記憶體等待的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);

新增完索引後，系統恢復正常。