死锁死锁还是死锁

[Zakero]

演示一 没有提交的事务，NOLOCK 和 READPAST 处理的策略：
查询窗口一请执行如下脚本：
CREATE TABLE t1 (c1 int IDENTITY(1,1), c2 int)
go
BEGIN TRANSACTION
insert t1(c2) values(1)
在查询窗口一执行后，查询窗口二执行如下脚本：
select count(*) from t1 WITH(NOLOCK)
select count(*) from t1 WITH(READPAST)
结果与分析：
查询窗口二依次显示统计结果为： 1、0
查询窗口一的命令没有提交事务，所以 READPAST 不会计算没有提交事务的这一条记录，这一条被
锁住了，READPAST 看不到；而NOLOCK 则可以看到被锁住的这一条记录。
如果这时候我们在查询窗口二中执行：
select count(*) from t1 就会看到这个执行很久不能执行完毕，因为这个查询遇到了一个死锁。
清除掉这个测试环境，需要在查询窗口一中再执行如下语句：
ROLLBACK TRANSACTION
drop table t1


“select count(*) from t1 就会看到这个执行很久不能执行完毕，因为这个查询遇到了一个死锁。”为什么！为什么~！
请各位帮小弟分析分析，实在不懂啊。
本人理解，第一次select with(nolock)没有加锁，第二次还是select with(nolock)何来的死锁

[發糞塗牆]

“select count(*) from t1 就会看到这个执行很久不能执行完毕，因为这个查询遇到了一个死锁。” 死锁应该在大概5秒内被杀掉，不至于不能完毕，你那个是阻塞吧?

[發糞塗牆]

另外，即使是select也有可能产生死锁

[Zakero]

引用 1 楼 DBA_Huangzj 的回复:

“select count(*) from t1 就会看到这个执行很久不能执行完毕，因为这个查询遇到了一个死锁。” 死锁应该在大概5秒内被杀掉，不至于不能完毕，你那个是阻塞吧?

好吧，我说的不够明白，无论是死锁还是阻塞都一样，为什么会出现呢

引用 2 楼 DBA_Huangzj 的回复:

另外，即使是select也有可能产生死锁

不是加了with(nolock)吗？

[Zakero]

好吧，我来送分的。

[發糞塗牆]

但是你的描述是说：select count(*) from t1 这句很久没完成，不是with (nolock)没完成，select count(*) from t1 没完成是因为窗口一为提交

[Zakero]

知道了 谢谢