11 секунд для удаления 240 строк в SQL Server

Я запускаю оператор delete:

DELETE FROM TransactionEntries
WHERE SessionGUID = @SessionGUID

Фактический план выполнения delete:

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 секунд?

• значение Avg. Disk Read Queue Length достигает 0.8
• the Avg. Disk sec/Read никогда не превышает 4ms
• the Avg. Длина очереди записи на диск достигает 0.04
• а Avg. Disk sec/Write никогда не превышает 4ms

Для чего нужны другие чтения? План выполнения не дает никаких указаний на то, что он читает.

Обновление:

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)

При 1,380 байтах на строку и 240 строках, это 340 кБ, которые должны быть удалены.

Противоречиво, что это может быть так сложно для 340 кБ.

Второе обновление: Дефрагментация

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')

поскольку INDEXDEFRAG является "онлайн-операцией" (т.е. он держит только IS Intent Shared locks). Я собирался затем вручную дефрагментировать остальные, пока не позвонили операционисты, сказав, что система мертва - и они перешли на выполнение всего на бумаге.

Что скажете вы; 50% фрагментация, и только 12% плотность сканирования, вызывают ужасную производительность сканирования индексов?