Quote: 引用:

Quote: 引用:

Quote: 引用:

Quote: 引用:

引用:
先会加个更新锁，然后再加个排它锁，由于没有走索引，会导致全表锁住，以便查找符合条件的数据。当然这个都依赖于当前的隔离级别。

那就是说，这样的语句并发量比较大的时候，会导致更新速度非常慢，对不。

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

果然是高手，观察够细致入微，向你学习。

数据量大的时候会慢我能理解，但是死锁我就理解不了了，
都是锁整个表，谁先来谁锁，怎么能造成死锁问题呢？

非常期盼你的回答。

这个也跟写法有关系，假设你的语句还不是那么简单，叫做进程1吧，进程1第一步先update，然后第二个update别的表A的某些数据，同时刚好有另外一个进程2又在慢慢update表A，和你这里一样，没有索引、数据量大，也锁表，进程2此时又要使用进程1正在update的数据，此时只能等待进程1释放锁，但是进程1又再等待进程2释放表A的锁，这样互相等待，就死锁了。SQLServer默认5秒会处理一个死锁，但是仅仅是杀掉进程，下次还是会出现死锁的。

明白了，非常非常感谢。

但是就你说的这种现象，怎么解决呢？
是不是Where xxx这部分利用索引就能解决了？