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

zengjd 2013-03-27 12:11:03

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

...全文

156 18 打赏收藏转发到动态举报

写回复

用AI写文章

18 条回复

切换为时间正序

请发表友善的回复…

发表回复

seusoftware 2013-03-27

打赏
举报

可以这样测试：会话1：

--session 1
select @@SPID --54
select * from A

begin 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锁是个过程锁。

zengjd 2013-03-27

打赏
举报

会锁住整个表么？

-Tracy-McGrady- 2013-03-27

打赏
举报

排他锁？？？

zengjd 2013-03-27

打赏
举报

引用 17 楼 DBA_Huangzj 的回复:

[quote=引用 16 楼 zengjd 的回复:] [quote=引用 15 楼 DBA_Huangzj 的回复:] [quote=引用 14 楼 zengjd 的回复:] [quote=引用 13 楼 DBA_Huangzj 的回复:] [quote=引用 12 楼 zengjd 的回复:] [quote=引用 9 楼 DBA_Huangzj 的回复:] [quote=引用 7 楼 zengjd 的回复:] 引用 5 楼 DBA_Huangzj 的回复: 先会加个更新锁，然后再加个排它锁，由于没有走索引，会导致全表锁住，以便查找符合条件的数据。当然这个都依赖于当前的隔离级别。那就是说，这样的语句并发量比较大的时候，会导致更新速度非常慢，对不。

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

發糞塗牆 2013-03-27

打赏
举报

引用 16 楼 zengjd 的回复:

[quote=引用 15 楼 DBA_Huangzj 的回复:] [quote=引用 14 楼 zengjd 的回复:] [quote=引用 13 楼 DBA_Huangzj 的回复:] [quote=引用 12 楼 zengjd 的回复:] [quote=引用 9 楼 DBA_Huangzj 的回复:] [quote=引用 7 楼 zengjd 的回复:] 引用 5 楼 DBA_Huangzj 的回复: 先会加个更新锁，然后再加个排它锁，由于没有走索引，会导致全表锁住，以便查找符合条件的数据。当然这个都依赖于当前的隔离级别。那就是说，这样的语句并发量比较大的时候，会导致更新速度非常慢，对不。

zengjd 2013-03-27

打赏
举报

引用 15 楼 DBA_Huangzj 的回复:

[quote=引用 14 楼 zengjd 的回复:] [quote=引用 13 楼 DBA_Huangzj 的回复:] [quote=引用 12 楼 zengjd 的回复:] [quote=引用 9 楼 DBA_Huangzj 的回复:] [quote=引用 7 楼 zengjd 的回复:] 引用 5 楼 DBA_Huangzj 的回复: 先会加个更新锁，然后再加个排它锁，由于没有走索引，会导致全表锁住，以便查找符合条件的数据。当然这个都依赖于当前的隔离级别。那就是说，这样的语句并发量比较大的时候，会导致更新速度非常慢，对不。

發糞塗牆 2013-03-27

打赏
举报

引用 14 楼 zengjd 的回复:

[quote=引用 13 楼 DBA_Huangzj 的回复:] [quote=引用 12 楼 zengjd 的回复:] [quote=引用 9 楼 DBA_Huangzj 的回复:] [quote=引用 7 楼 zengjd 的回复:] 引用 5 楼 DBA_Huangzj 的回复: 先会加个更新锁，然后再加个排它锁，由于没有走索引，会导致全表锁住，以便查找符合条件的数据。当然这个都依赖于当前的隔离级别。那就是说，这样的语句并发量比较大的时候，会导致更新速度非常慢，对不。

zengjd 2013-03-27

打赏
举报

引用 13 楼 DBA_Huangzj 的回复:

[quote=引用 12 楼 zengjd 的回复:] [quote=引用 9 楼 DBA_Huangzj 的回复:] [quote=引用 7 楼 zengjd 的回复:] 引用 5 楼 DBA_Huangzj 的回复: 先会加个更新锁，然后再加个排它锁，由于没有走索引，会导致全表锁住，以便查找符合条件的数据。当然这个都依赖于当前的隔离级别。那就是说，这样的语句并发量比较大的时候，会导致更新速度非常慢，对不。

發糞塗牆 2013-03-27

打赏
举报

引用 12 楼 zengjd 的回复:

[quote=引用 9 楼 DBA_Huangzj 的回复:] [quote=引用 7 楼 zengjd 的回复:] 引用 5 楼 DBA_Huangzj 的回复: 先会加个更新锁，然后再加个排它锁，由于没有走索引，会导致全表锁住，以便查找符合条件的数据。当然这个都依赖于当前的隔离级别。那就是说，这样的语句并发量比较大的时候，会导致更新速度非常慢，对不。

zengjd 2013-03-27