我正在处理一个死锁问题。
进程 A 正在对 TableA 执行简单的 INSERT，它对 TableB 有一个 FK
进程 B 正在对包含 TableA 和 TableB 的连接执行复杂的 SELECT
我将在下面包含跟踪信息，但基本上我认为正在发生的是由于 TableA 对 TableB 具有 FK，因此对 TableA 的插入导致了 TableB 的 Primany INDEX 上的排他锁 (X)。我们确实为那个 FK 启用了参照完整性，但是不需要通过插入到 TableA 来更新 TableB，所以我觉得奇怪的是，只需要一个排他锁来检查 FK 值的存在。
这是预期的行为吗？如果是这样，我可以做些什么来减轻这种情况？老实说，我没想到这样一个基本/香草插入会导致僵局。
此外，这不是我真正的问题，但如果您碰巧知道“子资源=满”意味着什么，我会很想知道。
编辑：只是要清楚僵局：
processInserting 正在插入到 TableA 并且在 TableB 上的主索引（TableA 的外键）上有一个 X 锁。ProcessSelecting 正在等待对该索引的 RangeS-S 锁定。
processSelecting 从包括 TableA 和 TableB 在内的许多表的连接中进行选择，并且在 TableA 上有一个 S 锁（因为它正在连接它）。ProcessInserting 正在等待此表上的 IX 锁。
编辑 2：提供更多细节。我正在调用 processSelecting 的“选择”查询是一个非常折磨人的查询，它使用一个折磨人的视图作为连接的一部分，所以看起来有点混乱。
这是 RoutePlan (TableA) 和 Form (TableB) 表的 DDL。