这个问题与此论坛主题有关。
在我的工作站和企业版两节点虚拟机集群上运行 SQL Server 2008 开发版，我将其称为“alpha 集群”。
删除带有 varbinary(max) 列的行所需的时间与该列中数据的长度直接相关。起初这听起来可能很直观，但经过调查，它与我对 SQL Server 通常如何实际删除行和处理此类数据的理解相冲突。
该问题源于我们在 .NET Web 应用程序中看到的删除超时（> 30 秒）问题，但为了本次讨论，我已对其进行了简化。
当一条记录被删除时，SQL Server 将它标记为一个幽灵，以便在事务提交后稍后由 Ghost 清理任务清理（参见Paul Randal 的博客）。在分别删除 varbinary(max) 列中包含 16 KB、4 MB 和 50 MB 数据的三行的测试中，我看到这种情况发生在包含行内部分数据的页面以及事务中日志。
我觉得奇怪的是，在删除过程中所有 LOB 数据页上都放置了 X 锁，并且这些页在 PFS 中被释放。我在事务日志以及DMVsp_lock的结果中看到了这一点dm_db_index_operational_stats( page_lock_count)。
如果这些页面不在缓冲区缓存中，这会在我的工作站和我们的 alpha 集群上创建 I/O 瓶颈。事实上，page_io_latch_wait_in_ms来自同一个DMV的实际上是整个删除的持续时间，并且page_io_latch_wait_count与锁定页面的数量相对应。对于我工作站上的 50 MB 文件，当以空缓冲区缓存 ( checkpoint/ dbcc dropcleanbuffers)启动时，这会转化为超过 3 秒，而且我毫不怀疑，对于大量碎片和负载不足的情况，时间会更长。
我试图确保它不只是在缓存中分配空间占用了那段时间。在执行删除而不是checkpoint方法之前，我从其他行读取了 2 GB 的数据，这多于分配给 SQL Server …
sql-server ×1