【故障公告】再次遭遇SQL語句執行超時引起網站首頁訪問故障

很是抱歉，昨天 18:40~19:10 再次遭趕上次遇到的 SQL 語句執行超時引起的網站首頁訪問故障，由此您帶來麻煩，請您諒解。

上次故障詳見以前的故障公告，上次排查下來覺得是 SQL Server 參數嗅探問題引發的，但在引發參數嗅探的漏洞被修復後再次出現故障說明上次的判斷是錯誤的。

今天出現故障時的表現與上次同樣，惟一不一樣的地方是此次比上次更糟糕，即便主備切換也沒法恢復。

後來咱們從 SQL 語句自己下手，給查詢首頁博文列表的 SQL 語句添加了時間條件才恢復正常。

SET @StartDate = dateadd(day, -2, getdate())
SELECT ...
FROM 
    blog_Content bc WITH(NOLOCK)
    ...
WHERE     
    bc.DateAdded >= @StartDate AND ...
ORDER BY 
    bc.[DateAdded] DESC

DateAdded 是博文表 blog_Content 的彙集索引字段，這段 SQL 語句以前長時間都使用了這個時間條件，但前段時間這個時間條件有時會形成數據庫 CPU 佔用高，後來去掉了。

加了 DateAdded 時間查詢條件後，雖然恢復了正常，但查詢速度不太理想，在執行計劃被緩存後耗時也要 800-900 毫秒。

今天上午咱們進一步對 SQL 語句進行了優化，仍是基於經過時間條件減小檢索範圍的思路，對博文與首頁的關聯表增長了查詢時間條件。

SELECT ...
FROM 
    blog_Content bc WITH(NOLOCK)
    INNER JOIN blog_Site_Links bl WITH(NOLOCK) on bc.ID = bl.EntryID
WHERE     
    bc.DateAdded >= @StartDate AND ...
    AND bl.CreatedTime > @StartDate ...
ORDER BY 
    bc.[DateAdded] DESC

這一優化效果明顯，查詢耗時降到了 50 毫秒之內。

另外，昨天在處理故障時，進行了一個索引修改的操做引起索引重建，結果形成數據庫 CPU 100% ， 形成幾分鐘全站訪問故障，由此您帶來麻煩，請您諒解。