Pageiolatch_sh调整索引后等待注意

Question

最近，数据库的许多查询正在计时。在调查期间，我发现查询处于悬浮状态，而wait_type为pageiolatch_sh。我没有注意到在服务器上暂停如此多的查询。自周六以来一直在发生这种情况。

几周前，DB服务器上的CPU持续100％。在尝试解决此问题时，我更改了几个索引，这些索引并未真正被使用，并导致了User_scans。更改索引后，服务器上的CPU使用情况下降了，该站点的性能通常更快，并且查看索引统计信息现在正在发生大量的User_Seeks，我认为这是一个好兆头。

但是，现在经过一两个星期后，即使CPU使用率不在100处，也已经开始观察大量查询，并且正在观察Pageiolatch_sh等待。有趣的是，即使CPU为100％，这些超时也没有以如此高的频率发生。

现在，维护索引也减慢了SQL Server的处理，因此我想知道新索引是否会导致更多的等待和超时？

Answer 1

从背景信息中，您提供的听起来好像您已经将服务器上的争夺点从CPU移至IO，这是由于实施了针对特定麻烦查询的索引策略的结果。

在大多数情况下（不涉及到您的索引策略的具体细节）这是预期的行为，因为CPU不再是争论点，因此等待自然是在其他地方发生的。

您现在看到的性能问题不一定是由您应用的索引修改引起的。进一步调查确定负责IO等待/以及您看到的超时的特定查询。您想查看这些方案中每种情况的执行计划，以确定可能的优化领域（首先寻找通常不受欢迎的操作，例如隐式转换，表扫描等）。

不想自以为是，但是由于参数嗅探的结果，由于查询计划的选择不佳，我经常在客户环境上遇到查询超时。这也可能是值得研究的。

在您调查期间使用一些方便的查询查看 Glenn Berry的SQL Server诊断查询. 。那里有许多奇妙的查询以查看IO，例如，哪些数据库负责最多的IO，哪些数据库数据文件看到的活动最多，查询会导致大多数读取/写入等等。

Answer 2

假设您的索引是最新的，从100％的CPU下降到较少的东西，而有超时问题意味着该应用程序现在正在等待锁或磁盘。 IO闩锁等待暗示磁盘。我会使用perfmon查看磁盘，以查看似乎是否有异常高的读数，请查看查询计划的确切查询计划，这些查询正在缓慢运行并重新考虑我对索引的工作。

另一个想法是，如果我做出了更改，此后情况似乎更糟，那么我要做的第一件事就是撤消这种变化。 IOW，将旧索引放回原处。

Answer 3

我必须同意约翰的观点，瓶颈刚刚向你移动。您可能会达到硬件的限制，或者更有可能需要一些工作。