非常抱歉，昨天 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% ， 造成几分钟全站访问故障，由此您带来麻烦，请您谅解。