我遇到了 SQL Azure 数据库的奇怪行为。在调查为什么存储过程突然开始超时（经过几个月的正常工作而没有任何问题）时，我发现了以下行为（代码来自我的 SQL Server mgmt studio 控制台，而不是来自存储过程，以及实际的表/字段名称替换，但它说明了问题）
我正在运行一个非常简单的查询
select * from dbo.mytable with (nolock) where field1 = 'somevalue'
查询只是挂在那里，状态栏中的指示器正在旋转，状态为“正在执行查询”，没有任何反应。作为一个实验，我让它执行了几个小时，但什么也没发生。SQL Azure 监视器不显示任何死锁。
任何其他字段过滤的类似查询会立即执行。但这是有趣的部分 - 如果我在 sql mgmgt studio 中打开另一个窗口并在第一个数据库挂起时在同一个数据库上运行相同的查询- 它会立即执行而没有任何问题。一旦我在第一个窗口中取消查询，如果我在第二个窗口中运行查询，它就会停止，并且它在并行窗口中运行的任何其他实例都可以正常执行。到目前为止，只有一个表才会发生这种情况，并且只有在按此特定字段过滤的情况下才会发生。不幸的是，这是数据库中的主表。
当我查询 sys.dm_exec_requests 时，它显示查询 wait_type 是 SE_REPL_SLOW_SECONDARY_THROTTLE，并且状态最初是running但随后更改为suspend。同时，另一个窗口中的相同查询以SOS_SCHEDULER_YIELD 的 wait_type运行。但它正在运行，而第一个没有。
一些背景信息：
SQL Azure 实例，1GB，已用空间 35MB，36 个活动连接
mytable - 61K 行，15 列，30MB，在标识主键上有一个聚集索引，在日期字段上有一个非聚集索引。
field1是从 varchar(16) null 派生的用户定义数据类型，但是 field 本身被定义为非 null。
mytable 中还有其他字段具有相同的数据类型并且也不为空，并且通过它们进行过滤显示没有问题。
mytable 包含应用程序的事务信息，插入率高。插入发生在小事务中，应该没有锁定问题。事务之外的所有读取都使用 nolock 提示进行。
不仅选择查询具有这种行为方式，而且该表上涉及该特定字段的任何类型的查询。
我将尝试在另一台服务器上创建此数据库，复制数据并查看问题是否仍然存在，但我感觉它在数据库实例中。
谢谢