死锁这个范畴很大，你需要先找出哪个语句导致的。其实根源还是太慢了，并且占用资源太多，使得其他事务要等待，给你几个改进建议：
1、如果表很大，使用2005以后的分区表，这样扫描的范围小很多。
2、改进索引，往往索引不好，会导致i/O很大、速度慢。好的索引可以把一个大查询秒杀，这样就算占用稍微大一点的资源很快释放了。其他事务也不用等待太久。
3、由于你一个事务中用到了另外一个真在等待的事务，所以导致了死锁，这点尽量能分开操作就分开操作。把速度提高的时候，可以使用with nolock来减少锁的占用。

http://topic.csdn.net/u/20120504/14/f17df33b-e678-40f0-a7e9-64224a091c70.html
看看这些有没有帮助

我感觉你还是把语句贴出来,你的5个的意识也不太清楚什么意识..5个事务吗! 正常的锁等待不叫死锁. 

频率有多高啊？
是死锁还是阻塞？

1、机器未崩溃之前，人不能先崩溃

2、死锁其实没那么复杂，无非是A请求B时，需要顺序使用锁1和锁2；B请求A时，需要顺序使用锁2和锁1，谁也不让谁，结果就死锁了。

3、找死锁的方法建议使用profiler，找到根源就更容易解决问题了。
http://www.simple-talk.com/sql/learn-sql-server/how-to-track-down-deadlocks-using-sql-server-2005-profiler/

4、good luck

“先删除, 后插入”，删除时需要先scan找到这笔资料，问题就出在这里，“交叉的检索和插入”导致死锁，最简单的办法就是修改sql server的默认隔离级别read committed为read uncommitted
如果觉得不放心，可以考虑使用SNAPSHOT_ISOLATION

使用SQL Server Profiler工具，选择Locks事件类的Lock:Deadlock（死锁）和Lock:Deadlock Chain（死锁链），然后跟踪看下你这5个并发，看看锁对应的SPID以及相关的先后顺序、发生时间等等，再进行判断。
对于代码，你可以将先删除，后插入放在一个事务中，然后写入存储过程。并发用户只调用这个存储过程，让MSSQL自己去根据数据库设置的事务等级自己去处理。
最后你要确实到底是死锁了，还是阻塞，还是正常的锁等待，这是完全不同的3个概念。

楼上几位讲的你综合排查下你的故障，看看能不能解决你的问题

表相互间的关系，逆向处理时子先主后，正常存储时主先子后。

我也想用数据库锁