11秒删除SQL Server中的240行

我正在运行删除语句：

DELETE FROM TransactionEntries
WHERE SessionGUID = @SessionGUID

删除的实际执行计划是：

Execution Tree
--------------
Clustered Index Delete(
   OBJECT:([GrobManagementSystemLive].[dbo].[TransactionEntries].IX_TransactionEntries_SessionGUIDTransactionGUID]), 
   WHERE:([TransactionEntries].[SessionGUID]=[@SessionGUID])
)

该表的聚类方式为SessionGUID，因此 240 行实际上是在一起的。

该表上没有触发器。

该操作需要：

• 持续时间：11821 毫秒
• CPU: 297
• 阅读数：14340
• 写入：1707

该表包含11个索引：

• 1 个聚集索引（SessionGUID)
• 1 个唯一（主键）索引
• 9 个其他非唯一、非聚集索引

我怎样才能弄清楚为什么会这样delete操作正在执行14,340读取，需要 11 秒？

• the Avg. Disk Read Queue Length达到0.8
• the Avg. Disk sec/Read永远不会超过4ms
• the Avg. Disk Write Queue Length达到0.04
• the Avg. Disk sec/Write永远不会超过4ms

What其他的读物有什么用？执行计划没有表明what它正在阅读。

Update:

EXECUTE sp_spaceused TransactionEntries

TransactionEntries  
  Rows      6,696,199
  Data:     1,626,496 KB (249 bytes per row)
  Indexes:  7,303,848 KB (1117 bytes per row)
  Unused:      91,648 KB    
            ============
  Reserved: 9,021,992 KB (1380 bytes per row)

With 1,380每行字节数，以及240行，即340 kB被删除。

与直觉相反的是，对于 340 kB 来说它是如此困难。

更新二：碎片化

Name                           Scan Density  Logical Fragmentation
=============================  ============  =====================
IX_TransactionEntries_Tran...  12.834        48.392
IX_TransactionEntries_Curr...  15.419        41.239
IX_TransactionEntries_Tran...  12.875        48.372
TransactionEntries17           98.081         0.0049325
TransactionEntries5            12.960        48.180
PK_TransactionEntries          12.869        48.376
TransactionEntries18           12.886        48.480
IX_TranasctionEntries_CDR...   12.799        49.157
IX_TransactionEntries_CDR...   12.969        48.103
IX_TransactionEntries_Tra...   13.181        47.127

我整理了碎片TransactionEntries17

DBCC INDEXDEFRAG (0, 'TransactionEntries', 'TransactionEntries17')

since INDEXDEFRAG is an "在线操作“（即它只包含IS意图共享锁）。然后我打算手动对其他系统进行碎片整理，直到业务部门打电话来，说系统已经死了 - 然后他们转而在纸上做所有事情。

你说什么； 50% 的碎片和只有 12% 的扫描密度，导致horrible索引扫描性能？

正如@JoeStefanelli 在评论中指出的那样，这是额外的非聚集索引。

您将从表中删除 240 行。

这相当于2640索引行，其中 240 个包含表中的所有字段。

根据它们的宽度以及您拥有的包含字段的数量，这可能相当于您看到的所有额外读取活动。

非聚集索引行肯定会NOT在磁盘上分组在一起，这会增加延迟。