达梦8 死锁模拟

1.创建两个简单的表t1_deadlock和t2_deadlock，每个表中仅仅包含一个字段a

SQL> create table t1_deadlock (a int);
操作已执行
已用时间: 6.906(毫秒). 执行号:23.
SQL> create table t2_deadlock (a int);
操作已执行
已用时间: 3.168(毫秒). 执行号:24.

2.每张表中仅初始化一条数据

SQL> create table t2_deadlock (a int);
操作已执行
已用时间: 3.168(毫秒). 执行号:24.
SQL> insert into t1_deadlock values (1);
影响行数 1
已用时间: 0.566(毫秒). 执行号:25.
SQL> insert into t2_deadlock values (2);
影响行数 1
已用时间: 0.803(毫秒). 执行号:26.
SQL> commit;
操作已执行
已用时间: 1.057(毫秒). 执行号:27.

3.在第一个会话session1中更新表t1_deadlock中的记录"1"为"1000"，不进行提交

SQL> update t1_deadlock set a = 1000 where a = 1;
影响行数 1
已用时间: 1.608(毫秒). 执行号:28.

4.在第二个会话session2中更新表t2_deadlock中的记录"2"为"2000"，不进行提交

SQL> update t2_deadlock set a = 2000 where a = 2;
影响行数 1
已用时间: 3.345(毫秒). 执行号:29.

5.此时，没有任何问题发生。OK，现在注意一下下面的现象，我们再回到会话session1中，更新t2_deadlock的记录

SQL> update t2_deadlock set a = 2000 where a = 2;

这里出现了"锁等待"（"阻塞"）的现象，原因很简单，因为在session2中已经对这条数据执行过这个操作，在session2中已经对该行加了行级锁。

注意，这里是"锁等待"，不是"死锁"，注意这两个概念的区别！

6.我们关注的"死锁"马上就要隆重出场了：在会话session2中，更新t1_deadlock的记录

SQL> update t1_deadlock set a = 1000 where a = 1;
update t1_deadlock set a = 1000 where a = 1;
[-6403]:死锁.
已用时间: 310.980(毫秒). 执行号:0.

7.以上种种现象说明什么？

说明： DM对于"死锁"是会做自动处理的，而不是不闻不问。

8.总结

死锁与阻塞的不同之处在于死锁包括两个或者多个已阻塞事务，它们之间形成了等待环，每个都等待其他事务释放锁。例如事务1给表T1上了排他锁，第二个事务给表T2上了排他锁，此时事务1请求T2的排他锁，就会处于等待状态，被阻塞。若此时T2再请求表T1的排他锁，则T2也处于阻塞状态。此时这两个事务发生死锁，DM数据库会选择牺牲掉其中一个事务。

参考：《DM8系统管理员手册》19.8 锁等待与死锁检测