如果我们对异步处理进行了数据库调用，那么异步处理实际上有帮助吗

在负载下的并发应用程序中，异步方法调用可以提高性能和吞吐量，因为调用线程可以腾出空间来做其他工作。

在某些边缘情况下，它不会有帮助，但如果您的应用程序除了等待数据库中的数据外，还花费了大量时间做其他事情，那么您应该会看到一些好处。这些优点适用于服务器端和GUI应用程序。

例如，如果您的应用程序花费300毫秒等待数据，300毫秒处理数据，并且您正在处理大量的同时请求，那么通过使用异步调用，您可能会使吞吐量翻倍，因为每个请求数据的线程都会立即释放，然后可以处理前一个请求返回的数据。

在实践中，您很少会看到这种程度的改进，因为请求不会以均匀的时间间隔到达，而且通常每个请求都不需要相同的工作量。不过，这种差异应该是显而易见的。

然而，如果你花300毫秒等待数据，而只花10毫秒处理数据，你就看不到有多大的改进。

在ASP.Net这样的环境中，这一点非常重要，因为可用于处理所有传入web请求的线程数量有限：如果所有线程都在数据库服务器上等待，则不会提供任何页面。

在windows窗体应用程序中，使用异步调用获取数据可以使UI在获取数据时保持响应，从而允许用户在无聊等待时选择取消。

明显的缺点是它使调用代码变得更加复杂。

这里有两个潜在的问题，第一个问题可以通过使用异步方法解决，第二个问题只能通过调整数据库来解决。

使用异步方法将允许您的客户端在等待服务器的同时执行其他处理，即在UI的情况下保持响应。

数据库锁定问题只能通过分析负载下的数据库来解决，看看哪些表被锁定，哪些存储的进程或进程导致锁定。

如果您确实需要大量的请求，您可能需要研究内存缓存或其他优化。

在描述的情况下，如果调用线程还有其他工作要做，那么使用异步调用肯定会有助于提高吞吐量。例如，如果线程1处理对服务器&进行数据库调用，即使您在该调用中使用.BeginInvoke（res）后跟.EndInvoke（雷斯），您仍在阻止该调用。

为了正确地扩展，您需要确保线程1还有其他工作要做，也许是准备另一个页面请求，直到它的数据库调用完成。这可以通过使用共享工作队列或类似管道模式的顺序队列来实现。查看本问题中的一些链接，了解有关异步设计模式的更多详细信息，以及它们如何帮助您提高服务器的吞吐量。

设计模式[1]：关于异步编程设计模式的资源

简短回答：

使用异步处理有助于，尤其是当您有数据库调用时。

在服务器应用程序中，应避免阻塞线程。如果在典型的请求中，您的服务器访问数据库，那么如果您同步执行此操作，则意味着您的线程在大多数时间都被阻塞，等待IO。当足够多的线程被阻塞时，这将给服务器带来瓶颈，并损害可扩展性，因为没有线程池线程可用于处理新请求，此外，由于没有线程可用于拾取要做的工作，您的CPU可能会利用不足。