死锁不仅在个人学习中，甚至在开发中也并不常见。但是一旦出现死锁，后果将非常严重。 首先什么是死锁呢？打个比方，就好像有两个人打架，互相限制住了(锁住，抱住)彼此一样，互相动弹不得，而且互相欧气，你不松手我就不松手。好了谁也动弹不得。 在多线程的环境下，势必会对资源进行抢夺。当两个线程锁住了当前资源，但都需要对方的资源才能进行下一步操作，这个时候两方就会一直等待对方的资源释放。这就形成了死锁。这些永远在互相等待的进程称为死锁进程。
创建一个Database，名为InvDB。
执行下面脚本创建person表并填充两条数据：
在SQL Server Management Studio的两个窗口中同时执行下面的查询：
这段代码在默认的READ COMMITTED隔离级别下运行，两个进程分别在获取一个排它锁的情况下，申请对方的共享锁从而造成死锁。
可见一个进程可以正常更新并显示结果，而另一个进程已经被回滚：
(1 row(s) affected) Msg 1205, Level 13, State 45, Line 8 Transaction (Process ID 55) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
启动 SQL Server Profiler，选择下面4种Events：
再执行一次上面的死锁实验，可以看到如下所示的死锁图：
非常有趣的一点是：第二次执行上述语句不会发生死锁！这是因为此时两个进程中，SQL Server会智能的识别出update语句是不需要做的，所以都不会去获取排它锁，当然也就不会死锁了。SQL Server 2008 的查询优化器还真是非常强大！
文章来源网络，作者：管理，如若转载，请注明出处：https://shuyeidc.com/wp/223164.html<
