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 锁等待与死锁检测
