实际上，上述死锁，有可能是一个执行计划走了Col2上的索引查找方式删除，需要先在Col2索引上加U锁
一个是走了走了全表扫描造成的，类似于delete t from TestDeadLock t with(index(0)) where Col2 in ( 'X000000000089','X000000000095')的执行计划
后者先在Col3上加U锁，然后找到其对应的RID，主键索引，Col2上的索引，依次加U锁，加X索引，这样才潜在死锁的可能性
写不下去了，钻研SQL Server的人实在太少了，如果是MySQL，一定会有大神回去做深入的分析，这个case笔者多次尝试重现它，包括使用Python多线程的方式模拟当时的场景，都无疾而终，无法重现
发生死锁的这个真实情况下的场景，也不会经常出现，笔者也只是偶尔捞到死锁的xml_deadlock_report尝试作分析，均无果。
这个死锁，是笔者遇到的不多的无法重现或者模拟出来的死锁，但愿有高手感兴趣的话，进一步做分析尝试，即便是推翻笔者猜测的结论，得出更有说服力的结果。
以上。