深圳智汇创想科技有限公司

参考 解决方案 修改，

此超时SQL 在5.16--5.18日的超时日志次数中，出现最多 3389次，排第1，尽快优化

查看25，26日的日志，依然有部分RB_Ebay_Listing_Queue_V2 更新的超时，由之前的3300多下降到780多

这个超时应该是目前这个ebylisting同步的服务并行运行了128个服务造成的死锁等待超时，

接下来整改了并发死锁的问题，在观察一下

新解决方案改造：

跟踪了这个超时的sql,最近在死锁里也比较多

问题分析：

进一步分析sql后发现：原sql里的left,in都可以去掉，改为下面的语句发现执行计划更简洁

select top (200) QE.LockGuid, QE.QueueState, QE.ExecTime
            FROM RB_Ebay_Listing_Queue_V2 QE
  INNER JOIN RB_Ebay_Listing_Basic_V2 B  
              ON B.CustomerID = QE.CustomerID
                AND B.ListingBasicID = QE.ListingBasicID
                AND B.OrderSourceID = QE.OrderSourceID
                AND B.SiteCode = QE.SiteCode
            WHERE QE.QueueState = 0 AND QE.QueueType =6

2.解决方案：

此改造 减少死锁的概率

 
UPDATE TOP(200) QE
SET    QE.LockGuid = '3cac6a5ce66446c2bce1b5fb8939485e',
       QE.QueueState = 1,
       QE.ExecTime = Getdate()
FROM   RB_Ebay_Listing_Queue_V2 QE
       INNER JOIN RB_Ebay_Listing_Basic_V2 B WITH(nolock)
               ON B.CustomerID = QE.CustomerID
                  AND B.ListingBasicID = QE.ListingBasicID
                  AND B.OrderSourceID = QE.OrderSourceID
                  AND B.SiteCode = QE.SiteCode
WHERE  QE.QueueState = 0
       AND QE.QueueType = 6; 

逻辑和之前是一样的，改造后执行计划更简单，添加了索引，速度更快，减少了死锁的概率

根据解决优化方案，现已将SQL再进一步进行了优化