删除11GB自定义DB日志大表耗时超10分钟，求原因解析

这问题我在生产环境踩过坑，太懂你这种看着执行卡着不动的焦虑了！哪怕没人访问这张表，DELETE CUSTOM_LOG 慢到离谱的原因主要集中在DELETE操作的本质开销和大Blob字段的特殊处理上，具体来说：

核心原因 #

• 逐行删除的固有开销：DELETE 是行级操作，哪怕你删全表，数据库也会逐行标记删除、维护事务日志（哪怕你说日志已禁用，大概率是指简单恢复模式，依然会生成轻量日志记录页的变更），还要同步更新表上的所有索引——如果这张日志表有索引（比如按时间、操作类型建的），每删一行就要更新索引条目，11GB的表对应的索引维护量会非常大。
• 大Blob字段的页回收代价：你的单条记录Blob字段就超过140MB，这类LOB数据（比如SQL Server的VARBINARY(MAX)）是存在单独的LOB数据页里的，删除包含LOB的记录时，数据库需要逐个释放这些大尺寸的LOB页，这个过程比回收普通数据页要复杂得多，IO开销呈指数级上升——毕竟单页就可能几十MB，11GB的表光LOB页的回收就需要大量的磁盘读写时间。
• 后台资源抢占：哪怕没有用户访问，数据库后台可能在跑自动统计信息更新、检查点、页整理等任务，这些会悄悄抢占CPU和IO资源，拖慢你的删除操作。

更快的替代方案 #

既然没人访问这张表，完全可以用更高效的方式处理：

• 优先用TRUNCATE TABLE：如果这张表没有外键约束，你也有TRUNCATE权限，直接执行 TRUNCATE TABLE CUSTOM_LOG 就行。它不会逐行删除，而是直接标记整个表的数据页为可用，日志量极小，11GB的表可能几秒就搞定。
• 分批删除（如果不能用TRUNCATE）：如果因为外键或其他限制不能用TRUNCATE，就分批小量删除，避免一次性占满资源：

  WHILE EXISTS(SELECT 1 FROM CUSTOM_LOG)
  BEGIN
      DELETE TOP(1000) FROM CUSTOM_LOG;
      WAITFOR DELAY '00:00:01'; -- 给数据库喘口气的时间
  END;
  

  这样你能看到操作的进度，也不会长时间卡住整个会话。
• 先删索引再删数据：如果表上有索引，先删除所有非聚集索引，删完数据后再重建索引——索引维护是删除慢的重要原因之一，去掉索引能大幅降低开销。

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