日期:2014-05-17  浏览次数:20457 次

推荐文章--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设计的问题,以后的版本会不会依然这样也不一定。
主要是通过它学习分析方法。
------解决方案--------------------
不错不错,辛苦了
------解决方案--------------------
不错不错,辛苦了