Just a comment on deadlocks and the with (nolock) option - That basically says that you don’t care what state the data is at. That is blocked by default because it is dangerous. Information that is dirty might be about to be undone. You can’t seriously say that this doesn’t matter because it isn’t a banking app, because ALL information that is being read from the database is being read for a reason. Information is acted on, either by a computer or by a user (even if that just means displaying to a user so they can make decisions). Even somethign as simple as a date of a post: Oh - I won’t respond to that post because it was made last year. or That concept is outdated… no - hang on, they just posted today.
Effectively, you are allowing decisions to be made based on information that will be wrong some of the time. That doesn’t make sense. Seriously - why are we bringing back information from the database if no decisions are based on that information? Useless information would never need to be retreived.
SOMETIMES I will use with (nolock) - especially when I know the information I am returning can’t be changed (one part of a row may be static, and another part may change). Also - if the decision being made by the information is allowed to be wrong some of the time (such as general monitoring processes), then I will also use it.
BUT - I agree with others that it is how you are trying to acheive your result that is the issue. A deadlock is a bit more complicated than 1 process trying to get access to a resource while another already has it. A deadlock is 2 processes trying to get to eachother’s resource at the same time, but neither will let go of their resources until they complete. So your problem isn’t with the Select, your problem will be that you have TWO updates. SQL Server only killed one of them, which is the one you had reported to you. Seriously - do a profile to determine what is running at the time the deadlock occured, and it will be clear the processes that are clashing (I use Lumigent Log Explorer, and it makes it very clear which resources are in conflict).
As for the select:
WHERE [ParentId] = @p0
If you had not used an asterisk (which is a BIG NO NO) AND indexed the information you were after, you may have found that no block due to the lock would have occured at all. That is, SQL Server 2005 on allows you to include data at the bottom page of the index. Once the index has been used to find the data, it can then return the data to you without reading from the actual table!!! If this data is not being edited, the index should not be locked. So that performing this query:
SELECT [UserName], [Topic]
WHERE [ParentId] = @p0
Stting the ParentID’s Index to have username and topic columns included with the index (look up the TSQL on this to see how this is created). This would locate your information FROM THE INDEX and never need to touch the data, and never need to even know the row was locked (take that MYSQL).
As for database technology (others have commented on this):
I have done speed comparisons, and for small apps I agree that MySQL is OK. But for larger apps Microsoft SQL Server out-strips MySQL like a Car vs a scooter. Then there is the power of Microsoft SQL Server. Sure MySQL is getting better, but there is nowhere near the programming ability. So it is still horses for courses - and as long as the SQL is iso standard, a user can still upgrade from MySQL to SQL Server. However, my personal thoughts are that using SQL Server throughout is a prefered option due to scalability, power and it is the tool our developers are most familiar with…