SQL Server 存储过程：他们排队吗？答案

【问题标题】：SQL Server Stored Procedures: do they queue up?SQL Server 存储过程：他们排队吗？
【发布时间】：2009-09-23 17:03:25
【问题描述】：

我应该能够找到答案，但我的 Google-fu 今天很弱。当我有一个 Web 应用程序多次调用同一个存储过程时，这些调用是排队还是独立运行？

【问题讨论】：

标签： sql sql-server tsql stored-procedures

【解决方案1】：

取决于存储过程正在做什么的isolation level。如果SP中所有事务的隔离级别都设置为READ UNCOMMITTED，则没有保护，多个线程可以同时执行同一个事务。

如果将其设置为更高的隔离级别，那么其他线程可能会被锁定在您的 SP 正在处理的资源之外，直到事务完成，从而有效地“排队”其他 SP 线程。

虽然没有显式存储过程队列。只要您的数据库有可用的连接和资源，它就会产生线程来满足请求。

【讨论】：

确实是存储过程中各个事务和DML语句的隔离级别，但在其他方面是准确的。
为更清晰地了解事务级别与 SP 级别进行了编辑。
好吧，这很有道理。谢谢！
虽然在技术上是准确的，但我可能会狡辩说，高隔离级别导致的“排队”（或非并行）程度发生在创建/释放锁的级别，而不是更高的级别单个查询本身的级别，并且可以合理地描述为与“排队”完全不同的现象，大多数人将其解释为整个查询在其他查询完成之前无法开始的行为。
取决于什么操作。未提交的读取仅适用于读取，即选择。无论隔离级别如何，所有数据修改都会锁定。因此，如果 proc 的多个实例尝试更新相同的行，则无论隔离级别如何，都会出现阻塞。

【解决方案2】：

两者兼而有之。存储过程的每次调用（更准确地说是客户端发送的每个请求）都会在 SQL 中创建一个任务，在 sys.dm_os_tasks 中可见。任务被分配给调度程序 (sys.dm_os_schedulers) 并等待工作人员 (sys.dm_os_workers) 可以运行它们。如果系统非常繁忙，那么任务将排队，这在sys.dm_os_schedulers 的work_queue_count 列中可见。更多详情请见Thread and Task Architecture。

在正常操作下，排队的效果是不可见的，因为系统会立即拿起提交的任务并开始运行它们。

客户端每个连接只能提交一个请求（MARS 是例外，而不是规则）。所以从客户端的角度来看，他必须在使用连接时对请求进行排队，但这隐藏在程序控制流中（即它必须等待请求返回才能提交新请求）。

【讨论】：

线程和任务架构上的链接正是我正在寻找的那种东西。谢谢！

【解决方案3】：

他们将独立运行。如果他们排队，如果您有一个使用大量存储过程的繁忙系统，这将导致一些大规模的可伸缩性问题。

这当然假设存储过程不会以一种会导致一个调用必须等待另一个调用完成的方式锁定资源。

【讨论】：