非常抱歉,昨天 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% , 造成幾分鍾全站訪問故障,由此您帶來麻煩,請您諒解。