【故障公告】再次遭遇SQL语句执行超时引起网站首页访问故障

很是抱歉，昨天 18:40~19:10 再次遭赶上次遇到的 SQL 语句执行超时引起的网站首页访问故障，由此您带来麻烦，请您谅解。html

上次故障详见以前的故障公告，上次排查下来觉得是 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 毫秒。spa

今天上午咱们进一步对 SQL 语句进行了优化，仍是基于经过时间条件减小检索范围的思路，对博文与首页的关联表增长了查询时间条件。code

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 毫秒之内。htm

另外，昨天在处理故障时，进行了一个索引修改的操做引起索引重建，结果形成数据库 CPU 100% ， 形成几分钟全站访问故障，由此您带来麻烦，请您谅解。blog