11 giây để xóa 240 hàng trong SQL Server

Question

tôi đang chạy một tuyên bố xóa:

DELETE FROM TransactionEntries 
WHERE SessionGUID = @SessionGUID 

Các kế hoạch thực hiện thực tế của xóa là:

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

Bảng này được nhóm bởi SessionGUID, vì vậy 240 hàng vật lý với nhau.

Bảng không có trình kích hoạt trên đó.

Các hoạt động diễn:

• Thời hạn: 11821 ms
• CPU: 297
• Đọc: 14340
• Viết: 1707

Bảng này chứa 11 chỉ số:

• 1 clustered index (SessionGUID)
• 1 duy nhất (khóa chính) chỉ số
• 9 phi độc đáo, chỉ số không clustered khác

Làm thế nào tôi có thể tìm ra lý do tại sao hoạt động delete này được thực hiện 14,340 đọc, và mất 11 giây?

• các Avg. Disk Read Queue Length đạt 0.8
• các Avg. Disk sec/Read không bao giờ vượt quá 4ms
• các Avg. Disk Write Queue Length đạt 0.04
• các Avg. Disk sec/Write không bao giờ vượt quá 4ms

gì là đọc khác cho? Kế hoạch thực hiện không cho biết chỉ số của nội dung số đang đọc.

---

Cập nhật:

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) 

Với 1,380 byte cho mỗi hàng, và 240 hàng, đó là 340 kB bị xóa.

Số lượt truy cập trực quan có thể khó khăn đến 340 kB.

Update Hai: Phân mảnh

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 

i Defrag TransactionEntries17

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

từ INDEXDEFRAG là một "trực tuyến hoạt động" (tức là nó chỉ giữ IS khóa chung Ý định). tôi sẽ tự tay chống phân mảnh cho đến khi các hoạt động kinh doanh được gọi, nói rằng hệ thống đã chết - và họ chuyển sang làm mọi thứ trên giấy.

Điều gì nói bạn; Phân mảnh 50% và mật độ quét chỉ 12%, gây ra khủng khiếp hiệu suất quét chỉ mục?

Answer 1

Sau khi đập đầu tôi về vấn đề hiệu suất nhiều-một-SQL, quy trình thao tác chuẩn của tôi cho một cái gì đó như thế này là:

1. Sao lưu dữ liệu
2. Xóa một trong những chỉ số trên bàn trong question
3. Đo hoạt động
4. Khôi phục DB
5. Lặp lại w/# 2 cho đến # 3 cho thấy sự thay đổi mạnh mẽ. Đó có thể là thủ phạm của bạn.

Answer 2

Khi @JoeStefanelli chỉ ra trong nhận xét, đó là các chỉ mục không được nhóm thêm.

Bạn đang xóa 240 hàng khỏi bảng.

Điều này tương đương với hàng chỉ mục, 240 trong số đó bao gồm tất cả các trường trong bảng.

Tùy thuộc vào độ rộng của chúng và số lượng trường được bao gồm, điều này có thể tương đương với tất cả hoạt động đọc bổ sung bạn đang xem.

Các hàng chỉ mục không được nhóm sẽ chắc chắn NOT được nhóm lại với nhau trên đĩa, điều này sẽ làm tăng sự chậm trễ.

Answer 3

Tôi nghĩ rằng việc lập chỉ mục có thể là thủ phạm đáng yêu nhất nhưng tôi muốn ném ra một khả năng khác. Bạn đã đề cập không có trình kích hoạt, nhưng có bất kỳ bảng nào có mối quan hệ khóa ngoài với bảng này không? Họ sẽ phải được kiểm tra để chắc chắn rằng không có hồ sơ nào trong đó và nếu bạn có xóa tầng được bật, các bản ghi đó cũng sẽ bị xóa.