I have data about deadlocks, but I can't understand why they occur

本秂侑毒 提交于 2019-11-29 00:27:30

You need to capture the deadlock graph. Attach Profiler and capture the Deadlock Graph Event class. Save the .XDL graph and add that info to your post.

Until then, is pretty obvious that your DB.Users.SingleOrDefault query requires an index on Name at least, if not on Name and Password:

CREATE INDEX idxUsersNamePassword on Users(Name,Password);

I expect Users already has an index on ID, and Articles has an index on ArticleID which covers AuthorID too. Assuming the Users.ID and Articles.ArticleID are PKs in they're respective tables, they are probably the respective's clustered key so it true. It worth double checking, though.

And, as I already answered you once in your previous post you decided to move on and leave un-answered, you should consider turning on Snapshot Isolation:

ALTER DATABASE ... SET READ_COMMITTED_SNAPSHOT ON

Besides that, storing password in clear text is a major #fail.

Update after deadlock info

There are three processes (requests):

  • A) ...F048 which is running the SELECT ... FROM Users WHERE Password = ... and Name = ...
  • B) ...0988 which is running the SELECT ... FROM Users WHERE Password = ... and Name = ...
  • C) ...FB88 which is running the UPDATE ...

The deadlock cycle is:

  1. C waits on Page IX lock, is blocked by A's S lock
  2. B waits on Page S lock, is blocked by C's IX lock
  3. A waits on parallel exchange resources, is blocked by B

The cycle therefore is C->A->B->C.

From the fact that the two SELECTs involved decide to 1) use a parallel plan and 2) use page locks is obvious that they do an end-to-end scan of the entire Users table. so the problem is, as I predicted, a lack of index on (Name, Password) on Users which causes the query to scan way too much data. Adding the index would turn the SELECT into a straight SEEK on the Nc index and a lookup on the Clustered index, and this would dramatically reduce the window of overlap with the UPDATE. Right now the UPDATE is pretty much guaranteed to conflict with all SELECTs, since every SELECT is guaranteed to read every row.

Adding the index will aleviate the immediate problem. Using Snapshot Isolation will mask the problem, since the end-to-end scans are still going to occur unless the (Name, Password) index is added. Or only (Name) will likely work too.

For future scalability, updating the Views column on every page view will not work. Delayed update, batch aggregate count update, vertically partition the Users table and take out the Views column are viable alternatives.

Martin Smith

Your issue has a lot of parallels with that here Diagnosing Deadlocks in SQL Server 2005

(Linq to SQL, Read Only transaction being deadlocked by a Read Write transaction)

If you are on SQL2005 or later perhaps setting up snapshot isolation as discussed on that thread will do the job. Otherwise please update your post with details of the version you are using.

In this situation (i.e. the type of data you're reading and the nature of the updates occurring on that data) I would run the user lookup query at read uncommitted isolation.

Alternatively, a more involved change. From the description you've posted, I would consider not maintaining the views count on the user record. I would instead record ViewCount against the Article, then dervive the total views for a user from the sum of Articles.ViewCount by AuthorID.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!