推荐文章--SQL Server上的一个奇怪的Deadlock及其分析方法

微软亚太区数据库技术支持组 官方博客

作品：

SQL Server上的一个奇怪的Deadlock及其分析方法

http://blogs.msdn.com/b/apgcdsd/archive/2012/02/28/sql-server-deadlock.aspx

大家看后说说感想，说的好的，分多点！
（虽然我也穷，但是好知识一定推荐！）


------解决方案--------------------
文章比较长，回复一下再看。
------解决方案--------------------

------解决方案--------------------
先回复，在看帖
------解决方案--------------------
死锁的问题一直都是很纠结的。
------解决方案--------------------
通常不选择给语句手动加锁。
------解决方案--------------------
好长，大概看了一下，update分步处理，执行计划有待加强啊.
------解决方案--------------------
通常不选择给语句手动加锁
------解决方案--------------------
求积分

------解决方案--------------------
同求啊
------解决方案--------------------
同求~~~
------解决方案--------------------
谢谢！学习了。。。。
------解决方案--------------------
学习..
------解决方案--------------------
受教了……
------解决方案--------------------
好哇，好哇
------解决方案--------------------
文章比较长，回复一下再看。
------解决方案--------------------
稍不留神，就会死锁！
------解决方案--------------------
对于这个死锁案例本身，将varchar(max)包含在一个索引里，是不太妥当的。这样会大大增加索引的复杂度，也增加了SQL Server的维护成本。解决这个索引的比较好的方法，是将字段d从索引里移除，或者把它改成一个有合适长度限制的varchar类型。

不是很赞同这个结论.但避免用varchar(max)还是很赞同的.
------解决方案--------------------
文章的确是长啊，表示暂时没耐心看完。。。 

------解决方案--------------------
谢谢LZ的分享，很有内容的帖子
------解决方案--------------------
感谢楼主分享！
------解决方案--------------------
语句执行了一个小时 还不见死锁 坑爹的吧
------解决方案--------------------
学习了 以前没有设过nvarchar(max)，都定义固定长度的
------解决方案--------------------
先学习。
------解决方案--------------------
谢谢分享！
------解决方案--------------------
谢谢分享
------解决方案--------------------
谢谢分享
------解决方案--------------------
当时我遇到这个问题也很疑惑，直到用sql profiler仔细分析，才发现这个问题。
------解决方案--------------------
我觉得这可能是SQL Server设计的问题，以后的版本会不会依然这样也不一定。
主要是通过它学习分析方法。
------解决方案--------------------
不错不错，辛苦了
------解决方案--------------------
不错不错，辛苦了