SQL设计：大表、线程访问序列化答案

【问题标题】：SQL Design: Big table, thread access serializationSQL设计：大表、线程访问序列化
【发布时间】：2009-11-29 19:07:01
【问题描述】：

我有一张大表（90k 行，大小 cca 60mb），其中包含大约 50 家酒店的免费客房容量信息。该表每小时的更新/插入很少。我的应用程序以每秒最多 30 次的速度向此（和连接的表）发送异步请求。

当我一次启动 30 个线程（使用 .NET 3.5 C# 的默认 AppPool 类）（使用随机有效的 sql 查询字符串）时，只有少数（cca 4）被异步处理，其他线程等待。为什么？是因为 SQL SERVER 2008 表锁定，还是因为 .NET 核心？还是别的什么？

如果是 SQL 问题，如果我将这个大表拆分为每个酒店模型一张表，是否有帮助？我的目标是一次至少提供 10 个线程。

【问题讨论】：

【解决方案1】：

这张桌子很小。它甚至不符合“中型”表的条件。这是微不足道的。

您可以每秒对其进行 30 次全表扫描，您可以将整个内容复制到 ram 中，没有服务器会受到丝毫打扰。

如果您的数据适合 ram，则数据库速度很快。如果你没有找到这个，你就做错了。因此我也认为问题都在客户端。

【讨论】：

【解决方案2】：

这很可能在 .NET 方面。如果是表锁定，则将处理更多线程，但它们将等待查询返回。如果我没记错的话，线程池有一个属性可以控制它们一次创建的实际线程数。如果挂起的线程多于该数量，则它们排队等待运行线程完成。检查一下。

【讨论】：

【解决方案3】：

您是否尝试过更改事务隔离级别？

即使从表中读取，Sql Server 也会锁定表

尝试将隔离级别设置为读取未提交，看看是否可以改善这种情况，

但请注意，您将阅读“脏”数据是可行的，如果这是解决方案，请确保您了解后果

这个链接解释了它是什么。

【讨论】：

我使用默认值（“READ COMMITTED”）。似乎问题出在客户端。也许我可以尝试在读取函数中使用“READ UNCOMMITTED”，在修改表数据的函数中使用“SERIALIZABLE”。你怎么看？
我会尝试 read uncommitted 检查是否是问题所在，然后从那里找出解决方案。一旦你测试过了，你应该知道它是在服务器上还是在 .Net 客户端上

【解决方案4】：

与其问，不如衡量。您的应用程序实际提交的每个 SQL 查询都会在服务器上创建一个请求，sys.dm_exec_requests DMV 显示每个请求的状态。当请求被阻塞时，wait_type 列显示一个非空值。您可以由此判断您的请求是否被阻止。如果他们被阻止，您也会知道他们被阻止的原因。

【讨论】：