RE:事务（进程 ID 63）与另一个进程已被死锁在 lock 资源上，且该事务已被选作死锁牺牲品。请重新运行该事务。

监听，找到冲突源，详细操作和解决办法参见 http://www.cnblogs.com/happyhippy/archive/2008/11/14/1333922.html 

解决方案 »

  1.   

    这种情况主要是DBMS自动帮你解决死锁的危险。但是有些死锁是不会自动帮你解决的，会让你手动kill掉进程才能解决。你可以用sp_who 64看看这个语句是干什么，然后查一下是那个操作和这个冲突了，导致死锁，一般情况是由于两个操作，一个先对某个或多个表进行非查询操作，把表进行排它锁，导致第二个操作，主要是查询，也就是你那个进程为64的操作，需要等待。而上一个操作有可能又引用了spid为64的里面某些资源。造成了循环等待，最后造成死锁。
    一般处理流程就是要看看非64的那个操作是否有合理的事务流程。这种原因一定是语句没写好，流程没处理好所导致的。
    另外，非查询的操作一定会锁表，这是合理的动作，所以不能避免，只能看看如何把这个操作过程缩短或者把资源通过另外一些方式引用。比如先进入临时表，然后再操作。
      

  2.   

    在处理数据时,有一条语句是先查询该表是否存在该项数据.存在则修改,不存在则insert应该是这句引起的.
      

  3.   

    用PROFILER跟踪LOCK。查出是哪些东西造成死锁的
      

  4.   

    就是多用户同时执行那一条SQL事务语句时
      

  5.   

    profiler跟踪...EventClass           LoginName     ClentProcessID  SPID          StartTime
    Lock:Timeout       sa       2364          70           2012-05-02 14:46:26.407