為了準(zhǔn)備今年的雙11很久沒(méi)有更新blog，在最近的幾次sqlserver問(wèn)題的排查中，總結(jié)了sqlserver幾種典型的等待類(lèi)型，類(lèi)似于oracle中的等待事件，如果看到這樣的等待類(lèi)型時(shí)候能夠迅速定位問(wèn)題的根源,下面通過(guò)一則案例來(lái)把這些典型的等待處理方法整理出來(lái)：
第一種等待.memory等待
早上接到一用戶(hù)反饋其RDS實(shí)例非常的慢，通過(guò)觀(guān)察sqlserver活動(dòng)會(huì)話(huà)監(jiān)視器（active monitor）的waiting tasks（類(lèi)似于mysql的thread running）可以看到有10多w的等待任務(wù),可以明確數(shù)據(jù)庫(kù)現(xiàn)在已經(jīng)出現(xiàn)了較大的瓶頸，緊接著通過(guò)resource waits看到數(shù)據(jù)庫(kù)中有大量的memory內(nèi)存等待：
看到是memory 資源等待后，為了立刻恢復(fù)用戶(hù)應(yīng)用，想到立刻去調(diào)大內(nèi)存，發(fā)現(xiàn)該實(shí)例已經(jīng)是24G了，看來(lái)一下os的空余內(nèi)存，還有較多的內(nèi)存剩余，所以將內(nèi)存調(diào)大到36G，發(fā)現(xiàn)resource waits還是在memory上等待，同時(shí)這個(gè)時(shí)候的cpu使用率飆升，達(dá)到了90%左右（之前在10%左右的等待）.這樣解決不了根本問(wèn)題，于是通過(guò)recent expensive queries,發(fā)現(xiàn)以下sql的邏輯讀很高，執(zhí)行非常頻繁：
SELECT * FROM RefundOrder_Message messages0_ WHERE messages0_.Order_Id=@p0;
也可以通過(guò)如下方式獲得造成內(nèi)存等待的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
發(fā)現(xiàn)該表只有一個(gè)主鍵索引：
創(chuàng)建一下索引：
create index ind_RefundOrder_Message_order_id on RefundOrder_Message(Order_Id);
第二種等待：latch等待
在索引加上去后，memory的等待立刻消失，但是resource waits的等待變?yōu)榱?lock：
通過(guò)以下內(nèi)部視圖可以發(fā)現(xiàn)如下調(diào)用出現(xiàn)了等待：
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;
得到阻塞其他會(huì)話(huà)的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是一張非常核心的視圖，里面關(guān)聯(lián)了訂單，訂單消息，訂單發(fā)貨等多個(gè)業(yè)務(wù)邏輯；查詢(xún)條件中代入了membercode為店鋪的名稱(chēng)，可能操作某個(gè)店鋪的訂單；
通過(guò)ViewSalesOrder視圖中的定義，membercode，IsObsolete ，OdCode 為salesOrder表的三個(gè)字段，查看salesOrder上并沒(méi)有相應(yīng)的索引，于是加上如下索引：
create index ind_salesOrder_member on salesOrder(membercode,IsObsolete,code)；
在添加完索引后，數(shù)據(jù)庫(kù)的waiting tasks 下降，batch requests提升：
第三種等待：lock
第三種等待是常見(jiàn)的等待，常見(jiàn)的情況在刪除，更新的時(shí)候由于條件中沒(méi)有合適的索引導(dǎo)致鎖定的記錄范圍太大，導(dǎo)致阻塞其他的會(huì)話(huà)請(qǐng)求：
用戶(hù)在在進(jìn)行壓測(cè)的時(shí)候發(fā)現(xiàn)一條更新語(yǔ)句執(zhí)行的非常慢，導(dǎo)致整個(gè)系統(tǒng)都卡?。?/p>
update DD_ShenHe set ZF = 0 where zf is null;
查看dd_shenhe表上面的索引：
可以看到表中并沒(méi)有zf字段的索引，而該表總共有400w的數(shù)據(jù)，zf 為null的有8000條，所以在zf字段添加索引是合適的：
Create index ind_dd_shenhe_zf on dd_shenhe(zf);
添加完索引后，系統(tǒng)恢復(fù)正常。
