Upage field1=avalue where xxx 会引发什么样的锁？where xxx这部分没有用到索引。

Question

Upage field1=avalue where xxx 会引发什么样的锁？
where xxx这部分没有用到索引。

Answer 1

可以这样测试：
会话1：
--session 1
select @@SPID --54
select * from Abegin tran
update A set ItemName = 'YES' where ItemID = 5会话2：--session 2
--用session 1里SPID
select * from sys.dm_tran_locks
where request_session_id = 54 锁产生在事务中，事务结束，锁也就释放了。表：IX锁，表示有请求正在更新这个表
页：IX锁，表示有请求正在更新这个数据页
行：X锁，正在更行这行，排开其他一切操作，在X锁申请到之前会先申请UPDLOCK，然后再转为X锁，U锁是个过程锁。

Answer 2

看用到什么锁直接查看sys.dm_tran_locks  

Answer 3

数据量大且并发大的时候，不仅会慢，甚至会导致阻塞或者死锁。万一field1是聚集索引键，就更麻烦了。另外你那update都写错了...

Answer 4

可以用4楼的方法来监控你单纯update生成的锁，估计会很多。

Answer 5

有些LOCK事件是获取后马上会释放掉的，所以用DMV会遗漏掉一些事件，比较好的方式是用SQL PROFILER来监控， 在LOCKS那节选择lock:acquired  跟lock:release 事件

Answer 6

果然是高手，观察够细致入微，向你学习。数据量大的时候会慢我能理解，但是死锁我就理解不了了，
都是锁整个表，谁先来谁锁，怎么能造成死锁问题呢？非常期盼你的回答。
这个也跟写法有关系，假设你的语句还不是那么简单，叫做进程1吧，进程1第一步先update，然后第二个update别的表A的某些数据，同时刚好有另外一个进程2又在慢慢update表A，和你这里一样，没有索引、数据量大，也锁表，进程2此时又要使用进程1正在update的数据，此时只能等待进程1释放锁，但是进程1又再等待进程2释放表A的锁，这样互相等待，就死锁了。SQLServer默认5秒会处理一个死锁，但是仅仅是杀掉进程，下次还是会出现死锁的。

Answer 7

果然是高手，观察够细致入微，向你学习。数据量大的时候会慢我能理解，但是死锁我就理解不了了，
都是锁整个表，谁先来谁锁，怎么能造成死锁问题呢？非常期盼你的回答。
这个也跟写法有关系，假设你的语句还不是那么简单，叫做进程1吧，进程1第一步先update，然后第二个update别的表A的某些数据，同时刚好有另外一个进程2又在慢慢update表A，和你这里一样，没有索引、数据量大，也锁表，进程2此时又要使用进程1正在update的数据，此时只能等待进程1释放锁，但是进程1又再等待进程2释放表A的锁，这样互相等待，就死锁了。SQLServer默认5秒会处理一个死锁，但是仅仅是杀掉进程，下次还是会出现死锁的。明白了，非常非常感谢。但是就你说的这种现象，怎么解决呢？
是不是Where xxx这部分利用索引就能解决了？

Answer 8

果然是高手，观察够细致入微，向你学习。数据量大的时候会慢我能理解，但是死锁我就理解不了了，
都是锁整个表，谁先来谁锁，怎么能造成死锁问题呢？非常期盼你的回答。
这个也跟写法有关系，假设你的语句还不是那么简单，叫做进程1吧，进程1第一步先update，然后第二个update别的表A的某些数据，同时刚好有另外一个进程2又在慢慢update表A，和你这里一样，没有索引、数据量大，也锁表，进程2此时又要使用进程1正在update的数据，此时只能等待进程1释放锁，但是进程1又再等待进程2释放表A的锁，这样互相等待，就死锁了。SQLServer默认5秒会处理一个死锁，但是仅仅是杀掉进程，下次还是会出现死锁的。明白了，非常非常感谢。但是就你说的这种现象，怎么解决呢？
是不是Where xxx这部分利用索引就能解决了？死锁除了慢之外，很重要的一个原因是没有顺序访问，你可以理解为两个或以上的进程进入了死循环。加快update速度即使不能根治死锁，也能减轻发生的频率。而且其他操作也会相对加快。没什么坏处

Answer 9

果然是高手，观察够细致入微，向你学习。数据量大的时候会慢我能理解，但是死锁我就理解不了了，
都是锁整个表，谁先来谁锁，怎么能造成死锁问题呢？非常期盼你的回答。
这个也跟写法有关系，假设你的语句还不是那么简单，叫做进程1吧，进程1第一步先update，然后第二个update别的表A的某些数据，同时刚好有另外一个进程2又在慢慢update表A，和你这里一样，没有索引、数据量大，也锁表，进程2此时又要使用进程1正在update的数据，此时只能等待进程1释放锁，但是进程1又再等待进程2释放表A的锁，这样互相等待，就死锁了。SQLServer默认5秒会处理一个死锁，但是仅仅是杀掉进程，下次还是会出现死锁的。明白了，非常非常感谢。但是就你说的这种现象，怎么解决呢？
是不是Where xxx这部分利用索引就能解决了？死锁除了慢之外，很重要的一个原因是没有顺序访问，你可以理解为两个或以上的进程进入了死循环。加快update速度即使不能根治死锁，也能减轻发生的频率。而且其他操作也会相对加快。没什么坏处就目前我们说的这种现象，除了通过加快Update的速度来减少发生的频率，就没有什么能根治的办法么？
期待你的回答。

Answer 10

果然是高手，观察够细致入微，向你学习。数据量大的时候会慢我能理解，但是死锁我就理解不了了，
都是锁整个表，谁先来谁锁，怎么能造成死锁问题呢？非常期盼你的回答。
这个也跟写法有关系，假设你的语句还不是那么简单，叫做进程1吧，进程1第一步先update，然后第二个update别的表A的某些数据，同时刚好有另外一个进程2又在慢慢update表A，和你这里一样，没有索引、数据量大，也锁表，进程2此时又要使用进程1正在update的数据，此时只能等待进程1释放锁，但是进程1又再等待进程2释放表A的锁，这样互相等待，就死锁了。SQLServer默认5秒会处理一个死锁，但是仅仅是杀掉进程，下次还是会出现死锁的。明白了，非常非常感谢。但是就你说的这种现象，怎么解决呢？
是不是Where xxx这部分利用索引就能解决了？死锁除了慢之外，很重要的一个原因是没有顺序访问，你可以理解为两个或以上的进程进入了死循环。加快update速度即使不能根治死锁，也能减轻发生的频率。而且其他操作也会相对加快。没什么坏处就目前我们说的这种现象，除了通过加快Update的速度来减少发生的频率，就没有什么能根治的办法么？
期待你的回答。有，不要在一个事务里面做太多事情，除非逻辑上是要一起实现的，如果两个update可以不一起执行，那么就分开来吧

Answer 11

果然是高手，观察够细致入微，向你学习。数据量大的时候会慢我能理解，但是死锁我就理解不了了，
都是锁整个表，谁先来谁锁，怎么能造成死锁问题呢？非常期盼你的回答。
这个也跟写法有关系，假设你的语句还不是那么简单，叫做进程1吧，进程1第一步先update，然后第二个update别的表A的某些数据，同时刚好有另外一个进程2又在慢慢update表A，和你这里一样，没有索引、数据量大，也锁表，进程2此时又要使用进程1正在update的数据，此时只能等待进程1释放锁，但是进程1又再等待进程2释放表A的锁，这样互相等待，就死锁了。SQLServer默认5秒会处理一个死锁，但是仅仅是杀掉进程，下次还是会出现死锁的。明白了，非常非常感谢。但是就你说的这种现象，怎么解决呢？
是不是Where xxx这部分利用索引就能解决了？死锁除了慢之外，很重要的一个原因是没有顺序访问，你可以理解为两个或以上的进程进入了死循环。加快update速度即使不能根治死锁，也能减轻发生的频率。而且其他操作也会相对加快。没什么坏处就目前我们说的这种现象，除了通过加快Update的速度来减少发生的频率，就没有什么能根治的办法么？
期待你的回答。有，不要在一个事务里面做太多事情，除非逻辑上是要一起实现的，如果两个update可以不一起执行，那么就分开来吧
明白了，谢谢