如果锁的资源为行锁，说明表没有主键，并且影响的数据范围非常小，此时SQL语句可能用到了非聚集索引，也可能没有用非聚集索引。

说明：星空产品下表都有聚集索引，不会存在没有聚集索引情况，这里只是作为演示用途。

1.输出死锁信息到错误日志dbcc traceon(1222,-1)，这样就可以在错误日志中查到死锁信息

2.准备数据

if object_id('testdeadlock')>0 drop table testdeadlock;

create table testdeadlock(fid int not null,fname varchar(20));

insert into testdeadlock values(1,'bob'),(2,'joe'),(3,'tom');

create index idx_1 on testdeadlock(fid)

insert into testdeadlock select * from testdeadlock  --重复执行，产生如10W行数据

commit;

dbcc dbreindex(testdeadlock)

3. 测试

事务一：

步骤1：

begin tran

update top(1) testdeadlock set fid=fid where fid=2;--由于表有大量的重复数据，如果不指定更新行大小，那么锁会变为表锁

--步骤3：

update top(1) testdeadlock set fid=fid where fid=1;

rollback

事务二：

步骤2：

begin tran

update top(1) testdeadlock set fid=fid where fid=1;

--步骤四：

update top(1) testdeadlock set fid=fid where fid=2;

rollback

事务二的会话会出现下面信息（选择成本低的作为牺牲品）

4.查看执行计划，确保使用了索引查找

--说明更新语句使用了索引查找，由于没有聚集索引，所以数据更新的时候是表更新操作（有无聚集索引时，数据表的存储模式，请参考微软官方文档，这里不做说明）

5.使用sp_readerrorlog查看死锁信息

6.分析死锁资源

死锁资源为

        RID: 5:1:2594560:1

        RID: 5:1:2594560:0

说明：

        5：数据库ID

        1：文件ID

        2594560：页ID

        0/1：行的slot位置

    （基于锁资源的说明可以参考：

https://docs.microsoft.com/en-us/troubleshoot/sql/performance/understand-resolve-blocking）

如何知道更新的是哪行数据，可以通过dbcc page来看

dbcc page(5,1,2594560,3) WITH TABLERESULTS

找到slot=0和slot=1的数据，我们就看到了对应的数据的详细信息了。