背景：
我们有一个使用SQL Server 2008数据库的应用程序。 我们正试图优化这个应用程序。 它是单线程的，我们通过logging/分析应用程序注意到最大的瓶颈是数据库读/写。 一些电话花费了100ms，这对我们来说是太长了。 在其他优化中，我们将这些调用中的一部分拆分为一个单独的线程。 单单从这个变化来看，我们看到处理时间有了很大的改进（代码几乎完全一样，只是有些已经被转移到了不同的线程中）
题：
假设在内存中运行代码的时间可以忽略不计，我会猜测在另一个线程中执行某些读/写操作不会带来性能上的提升。 我觉得如果SQL Server只是简单地排队请求，读/写无论如何都不可能同时发生，所以处理时间将是相似的。 不是这种情况。
我想知道SQL Server如何处理来自不同线程的两个同时请求（任何组合的读/写）。 它能以某种方式同时执行它们吗？
总而言之，我假设Query1 + Query2一个接一个地调用的总时间将类似于同时调用的Query1 + Query2。
这是在双核心服务器上运行。
SQL Server是一个多用户数据库。 这主要是为了处理多个同时发生的请求。
理想情况下，两个连续执行A + B的查询在同时执行时将采用MAX（A，B）。
为了防止读取或写入损坏的数据，SQL Server使用事务和locking 。 除此之外，应用程序也可以pipe理并发（例如乐观 ）。
我认为David B提供了一个很好的答案，但我只是在这里用一个例子来扩展它。
假设您的数据库中有两个表，Table_A和Table_B。 该服务器有多个处理器。 此外，磁盘子系统把每个表放在一个单独的驱动器/ LUN /主轴（不pipe正确的术语是什么，我不是一个大硬件人）。 此外，服务器有多个NIC卡。
如果两个用户都访问数据库，而另一个用户希望写入Table_A，而另一个用户想从Table_B中读取数据，那么希望您可以看到请求如何同时进入不同的网卡，由不同的CPU /内核同时处理，IO活动可能全部同时发生在不同的磁盘上。
现在，在现实世界中很less这么简单。 根据您的硬件和应用程序的使用情况，您通常在一个或多个这些方面存在瓶颈。 另外，如果两个用户都尝试访问同一个表中的相同行，则可能会导致资源瓶颈。 所以，在现实生活中，有很多人花费大量的时间去寻找哪些资源正在造成应用程序的瓶颈，并摆脱这些瓶颈。 但至less在一些地方可以并行处理事情。
你的问题意味着，在改进之前，SQL访问是顺序的，即后续的查询是在相同的连接上，在相同的代码线程中一个接一个地执行的。
将逻辑移至不同的线程将导致两种截然不同的效果：首先，您的代码不必再等待每个查询完成，然后SQL查询将并行（在某种程度上），从而允许SQL Server优化数据文件访问 – 远远比你的代码更好。
假设代码由多个纯SQL调用组成，前者的影响可能与后者相当。