请教这种情况下死锁发生的可能原因。

Question

公司网站（ASP语言）的IIS及数据库在一台服务器上，表中数据量相对比较多。其中，在对数据量最大的表中进行查询操作时，经常出现死锁的现象。但纯粹的查询会引起死锁么？（单机情况下模糊查询的速度是很慢）还是由同时进行的更新等操作引起的？

Answer 1

公司网站（ASP语言）的IIS及数据库在一台服务器上，表中数据量相对比较多。其中，在对数据量最大的表中进行查询操作时，经常出现死锁的现象。但纯粹的查询会引起死锁么？（单机情况下模糊查询的速度是很慢）还是由同时进行的更新等操作引起的？
但纯粹的查询会引起死锁么？我认为一般来说不会.应该是由同时进行的更新等操作引起的.另:单机情况下模糊查询的速度是很慢,是否缺少主键或索引,或机器本身配置不高?

Answer 2

那么，怎么查询死锁是由什么操作引起的呢？在错误日志中查找，或者用事件探测器来查看，还是使用论坛上邹建邹老大写的存储过程？在ASP代码中,rs.open sql后面的参数对于给数据库中加的锁有没有影响？有什么样的 影响？

Answer 3

To => dawugui(潇洒老乌龟):
模糊查询速度比较慢的原因是执行了全表扫描like '%xxx%'，那个表中有百万条记录。
虽然有索引，但因为like '%xxx%'而失效。主键则没有。

Answer 4

在2000以下，like的性能一般比charindex , patindex 差 在select后表明后面声明  with(nolock) ,看看速度快了没，如果快了，说明其它处理事务的时间过长可以考录全文索引

Answer 5

好像默认有脏读锁，如果你在读取的时候，别的又来更新数据的话，就有可能的。所以如果不怕脏读的话，还是用NoLock好了。

Answer 6

在 select命令执行时
SQL Server 通常会对对象进行共享锁锁定,
通常加共享锁的数据页被读取完毕后,共享锁就会立即被释放.
lz查询很慢的情况进行更新可能会引起死锁

Answer 7

现在用邹建邹老大的那个查看死锁的存储过程查看时，牺牲进程正在执行的都是sp_cursoropen;1，不解其意啊。

Answer 8

那个查询网页经常再现某某某进程被作为死锁牺牲品kill的情况。