我有一个 Web 服务，用于管理文件系统上的文件，这些文件也在 Microsoft SQL Server 数据库中进行跟踪。我们有一个 .NET 系统服务来监视使用 FileSystemWatcher 类添加的文件。当文件添加回调来自 FileSystemWatcher 时，有关文件的元数据将添加到我们的数据库中，并且运行良好。
我现在遇到了一些可扩展性问题。我正在快速连续地将大量文件添加到文件系统中，这最终会通过文件添加来敲击数据库，从而导致锁定我的 Web 前端。
我还没有解决数据库可扩展性问题，所以我正在尝试提出缓解策略。我在考虑也许缓存文件添加并且每五分钟左右将它们写入数据库，但我不确定这有多实用。无论如何，这些数据都需要在某个时候进入我们的数据库，因此在某个时候它必须受到重击。也许我可以将每秒写入的文件数据库条目数限制为一定数量，但是我冒着使该数量小于添加文件的速率的风险。我怎样才能最好地解决这个问题？
您是否考虑过使用SQL Server Service Broker 之类的东西？这样一来，您可以一次性推送大量条目，并将插入到您的数据库中。
基本上，您会将消息推送到队列中，然后由接收器存储过程使用，该存储过程将为您执行插入。您可以限制执行的接收器的最大数量，以帮助解决 Web 界面中的响应问题。
这里有一篇不错的介绍论文。尽管它是针对 2005 年的，但在 2005 年和较新版本的 SQL Server 之间并没有太大变化。
你有一个性能问题，你应该使用像Waits 和 Queues这样的性能调查方法来解决它。一旦您确定了实际问题，我们就可以讨论解决方案。
这只是一个猜测，但假设通知“更新元数据”代码是直接插入，可能的问题是您为每个通知生成一个事务。这会导致提交刷新等待，请参阅诊断事务日志性能。批量提交（在提交之前聚合多个通知）是规范的解决方案。
第一种选择是使用缓存来处理大量数据。或使用聚类分析大量数据。请点击这里了解更多信息。