asp.net-mvc - SQL Server 存储过程减慢查询速度

Question

8/19/2014 - 这个问题仍然悬而未决。现在看来，即使我没有运行存储过程，这种情况也在发生。我还没有足够的经验来了解什么样的事情会导致 SQL 服务器像这样变慢。

---

我有一个对我来说很奇怪的问题。两件看似无关的事情现在已经关联了两次。

首先，我在 SQL Server 2008 Express R2 中有一个存储过程，它包装在一个事务中(代码如下)。在交易中，

• 将早于特定日期的记录从日志表复制到日志存档表中。
• 然后记录从日志表中删除。

数据库位于专用托管服务器上。

其次，我有一个通过 AJAX 加载三个 HTML 表格的网站页面。后面的代码是从日志表所在的同一个数据库中读取的，但是没有一个数据库表重叠。查询是通过 LINQ-to-Entities 使用 Entity Framework 6 执行的。它们是有些复杂的查询，但是在正常情况下，启动 AJAX 调用后，每个 HTML 表格的加载时间都不到 5 秒。该网站位于共享托管服务器上。

网站上没有其他查询速度慢。只有这两个。

出于某种原因，在我执行存储过程后，网页上的AJAX 查询运行时间过长，以至于它们超时并且没有数据加载。我不得不将超时窗口打开到 180 秒，以便他们甚至有机会在超时前加载。

我能够使查询恢复到“正常”速度的唯一方法是停止 SQL Server 服务，然后重新启动它。之后，网页会快速加载。

我担心的是，我创建的存储过程导致某些东西在 SQL Server 中挂起，或者内存问题，或者其他什么。

存储过程如下:

USE [Main]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author:      Jason Watts
-- Create date: 7/30/2014
-- Description: Archives every record in ErrorLogs 
--              older than 2 months into the 
--              ErroLogsArchive table.
-- =============================================
ALTER PROCEDURE [dbo].[ArchiveErrorLogs] 
AS
BEGIN
    -- SET NOCOUNT ON added to prevent extra result sets from
    -- interfering with SELECT statements.
    SET NOCOUNT ON;

    -- Init variables and error code
    Declare @TransactionCountOnEntry int;
    Declare @ErrorCode int;
    Select @ErrorCode = @@Error;

    -- Begin transaction processing for rollback option
    If @ErrorCode = 0
    Begin
       Select @TransactionCountOnEntry = @@TranCount;
       BEGIN TRANSACTION;
    End

    -- Get the current date/time
    Declare @ArchiveDT datetime;
    SELECT @ArchiveDT = DATEADD(m, -2, GETDATE());

    -- Copy the records from ErrorLogs to ErrorLogsArchive
    If @ErrorCode = 0
    Begin
        INSERT INTO ErrorLogsArchive (Area,Library,Method,ErrorLevel,[Message],Stacktrace,LogDate)
        SELECT Area,Library,Method,ErrorLevel,[Message],Stacktrace,LogDate
        FROM ErrorLogs
        WHERE LogDate <= @ArchiveDT;

        Select @ErrorCode = @@ERROR;
    End

    -- Delete the records from ErrorLogs
    If @ErrorCode = 0
    Begin
        DELETE FROM ErrorLogs
        WHERE LogDate <= @ArchiveDT;

        Select @ErrorCode = @@ERROR;
    End

    -- End the transaction
    If @@TranCount > @TransactionCountOnEntry
    Begin
       If @ErrorCode = 0
          COMMIT TRANSACTION;
       Else
          ROLLBACK TRANSACTION;
    End

    -- Return
    Return @ErrorCode;
END

在我今天早上运行程序之前，原始日志表有 150 万条记录。第一次我要移动超过 3 个月的地方，它成功地移动了 700,000 条记录。尽管运行大约需要 5 1/2 分钟。然后我将它缩短到 2 个月，它在大约 1 1/2 分钟内又移动了 200,000 条记录。

每次运行后，网页表加载速度变慢，然后在重新启动 SQL Server 服务后恢复正常。我不明白是什么导致了速度下降。如果不是发生过两次，我不会认为它们有关联。

更新

正如我上面提到的，同样的 2 个查询现在运行缓慢，我还没有执行存档功能。我觉得这里有一些简单的问题，我只是不知道它可能是什么。

Answer 1

Ghost Cleanup 导致性能下降。

继续阅读 Ghost cleanup in depth

简而言之，删除操作不会删除/删除行。 “已删除”行被标记为删除，然后(逐渐地)一次重新分配“内存”1-10 页。这是 SQL Server 的“优化”。

---

执行计划

由于 Execution Plan 的存在，这种陈旧的垃圾收集变得更加复杂。 (阅读)试图“保留”已删除的行。结果是有问题的 Cluster F，它类似于但并未退出死锁。

您可以使用 DBCC FREEPROCCACHE 删除执行计划

---

重影清理中的已知错误:

更糟糕的是，SQL Server 存在一个已知错误，无法正确处理数以百万计的幻影记录

ghost_record_count values keep increasing in SQL Server 2008 R2 or in SQL Server 2008

---

重新启动 SQL Server:

我怀疑，除了刷新所有执行计划之外，新启动的 SQL Server 更加重视立即“清理”重影图像。

---

跟进

来自 SQLMag，When a Delete isn’t Really a Delete

So when do the deleted records get removed? The act of deleting a record doesn’t put that record on the queue of work for the ghost cleanup task. It’s not until the database page on which the deleted record resides is read again by the SQL Server Storage Engine that the page will be queued up for definite ghost record removal. The ghost cleanup task will look at its queue of things to do, and if it is empty, it will process part of a database on an instance to see if the database has ghost records to be removed. The only way to make sure that the space used by a ghost record is freed up quickly is to do something such as a table scan or an index rebuild so that all pages in the table are accessed by the Storage Engine and ghost records are queued for removal.

• 似乎受影响的表与日志表在同一“页面”上。

• 据我所知，有多种选择。表扫描可能会有所帮助。