我目前遇到一个奇怪的问题，我对SQL服务器的理解并不完全符合。我们使用SQL作为内部存储服务的文件存储，我们的数据库中有大约50万行。大多数文件（86％）是1mb或以下，但即使在我们的数据库的新副本中，我们只是为了测试目的而使用数据填充表，看起来经常在BLOB中存储大量数据的行当我们的SQL服务器负载时导致超时。我对SQL服务器如何删除行的理解是它是一个垃圾收集过程，即该行被标记为ghost，并且在将更改复制到事务日志之后，该行将被ghost清理过程删除。这告诉我，无论blob中的数据大小如何，行删除都应该接近瞬时。但是，当删除这些行时，我们肯定会遇到大量的超时和令人惊讶的低性能。
在我们的测试数据集中，超过30mb的文件会导致此问题。这是一个边缘情况，我们不经常遇到这些，即使我们正在研究SQL文件流作为我们的一些问题的解决方案，我们也试图缩小这些问题的起源。
我们正在交易中执行删除操作。我们还对元数据（例如文件大小统计信息）执行更新，但这些更新存在于远离文件数据本身的单独表中。层次结构数据存储在包含文件信息的表中。
实际上，最重要的是，我们对重要的删除工作并没有那么多，我们在BLOB中包含大量数据的行上找不到任何对低删除性能的引用。我们正试图确定这是否是一个值得探索的途径，或者它是否必须是我们围绕导致该问题的删除的过程之一。是否有任何可能发生这种情况的情况？当许多这些删除同时发生时，数据库服务器是否常常达到完全超时的程度？如果它存在，有没有办法解决这个问题？
答案 0 :(得分：2)
您正在描述性能问题，并且与任何性能问题一样，您需要先通过测量来处理它。猜测会让你无处可去。因此，使用适当的调查方法，Waits and Queues再次完美适用。观察，收集数据和分析。您肯定会发现导致查询超时的原因（它是否阻塞？是IO吗？是CPU吗？），根据实际发现我们可以推荐一个正确的修复。
至于回答你的问题：不，删除BLOB不会导致你描述的任何症状。这些是典型的 contention 症状。