SQL Delete删除少量行却执行极慢，如何排查原因？

• 索引维护开销过大：你的表存在10个非聚集索引，每删除一条记录，数据库需要同步更新所有这些索引的条目。哪怕仅删几十条，累积的索引更新操作也会带来可观的开销。可以尝试临时禁用非必要索引，执行删除后再重建；也可以查看执行计划，确认索引更新环节的资源占比。

• 锁与阻塞问题：删除操作需要获取排他锁，若此时有其他事务持有该表/相关数据页面的锁，会导致删除操作进入等待状态。可通过以下语句排查阻塞情况：

  SELECT 
      blocking_session_id,
      session_id,
      wait_type,
      resource_description
  FROM sys.dm_tran_locks
  WHERE resource_type = 'OBJECT' 
    AND resource_associated_entity_id = OBJECT_ID('dbo.PermitsTracked_Requirements_XREF');
  

• 统计信息过期：即使同条件的SELECT查询很快，删除语句的执行计划仍可能因统计信息过时，选择低效的执行路径。执行以下语句更新统计信息后再测试：

  UPDATE STATISTICS dbo.PermitsTracked_Requirements_XREF WITH FULLSCAN;
  

• 事务日志性能瓶颈：若数据库处于完整恢复模式，删除操作会生成大量事务日志。如果日志文件过小、自动增长步长设置不合理（比如每次仅增长1MB），会导致频繁的日志文件扩展，严重拖慢删除速度。可预先扩容日志文件，或临时切换到简单恢复模式（操作前务必做好数据备份）。

• 索引/表碎片严重：长期的增删改操作可能导致表或索引碎片率过高，删除操作在碎片密集的页面执行时，会额外产生页面分裂或资源消耗。可查询碎片情况：

  SELECT 
      index_id,
      index_type_desc,
      avg_fragmentation_in_percent
  FROM sys.dm_db_index_physical_stats(
      DB_ID(), 
      OBJECT_ID('dbo.PermitsTracked_Requirements_XREF'), 
      NULL, 
      NULL, 
      'DETAILED'
  );
  

  若碎片率超过30%，可重建索引；10%-30%之间可重组索引。

• 执行计划不合理：虽然你创建了专用索引，但删除语句的执行计划可能未正确使用它。可以查看实际执行计划：

  • 确认是否走了IDX_PermitID_PTRXID索引，还是执行了全表扫描
  • 尝试把IN子查询改成EXISTS关联，比如：

    delete ptrx
    from PermitsTracked_Requirements_XREF ptrx
    where ptrx.PermitID = @permitID
      and exists (select 1 from __tmpPTRXID tmp where tmp.PTRXID = ptrx.PTRXID)
    

  部分场景下EXISTS的执行效率会优于IN。

内容的提问来源于stack exchange，提问作者bzamfir