我们在Stack Overflow SQL Server 2005数据库中看到了一些有害但罕见的死锁条件.
我附上了探查器,使用这篇关于解决死锁问题的优秀文章设置了一个跟踪配置文件,并捕获了一堆示例.奇怪的是,死锁写入始终是相同的:
UPDATE [dbo].[Posts]
SET [AnswerCount] = @p1, [LastActivityDate] = @p2, [LastActivityUserId] = @p3
WHERE [Id] = @p0
另一个死锁声明各不相同,但它通常是对posts表的一些简单,简单的读取.这个人总是在僵局中被杀死.这是一个例子
SELECT
[t0].[Id], [t0].[PostTypeId], [t0].[Score], [t0].[Views], [t0].[AnswerCount],
[t0].[AcceptedAnswerId], [t0].[IsLocked], [t0].[IsLockedEdit], [t0].[ParentId],
[t0].[CurrentRevisionId], [t0].[FirstRevisionId], [t0].[LockedReason],
[t0].[LastActivityDate], [t0].[LastActivityUserId]
FROM [dbo].[Posts] AS [t0]
WHERE [t0].[ParentId] = @p0
要非常清楚,我们没有看到写/写死锁,而是读/写.
我们目前混合使用LINQ和参数化SQL查询.我们已添加with (nolock)到所有SQL查询中.这可能对一些人有所帮助.我们昨天修复了一个(非常)写得不好的徽章查询,每次运行时间超过20秒,每分钟运行一次.我希望这是一些锁定问题的根源!
不幸的是,我在大约2小时前遇到了另一个死锁错误.同样的症状,同样的罪魁祸首写.
真正奇怪的是,您在上面看到的锁定写入SQL语句是非常特定的代码路径的一部分.它仅在向问题添加新答案时执行 - 它使用新答案计数和最后日期/用户更新父问题.显然,这与我们正在进行的大量读取相比并不常见!据我所知,我们在应用程序的任何地方都没有进行大量的写操作.
我意识到NOLOCK是一个巨大的锤子,但我们在这里运行的大多数查询都不需要那么准确.如果您的用户个人资料已过期几秒,您会关心吗？
正如Scott Hanselman在这里讨论的那样,将NOLOCK与Linq一起使用有点困难.
我们正在调整使用的想法
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
在基本数据库上下文中,以便我们所有的LINQ查询都有此设置.没有它,我们必须在3-4行事务代码块中包装我们所做的每个LINQ调用(好吧,简单的读取,这是绝大多数),这很难看.
我想我有点沮丧的是,SQL 2005中的琐碎读取可能会使写入死锁.我可以看到写/写死锁是一个很大的问题,但 …