Giải thích được yêu cầu để XÓA chậm với SQL Server

Tôi muốn có thêm một số hiểu biết / lý do cho hành vi xóa SQL Server. Chúng tôi có một cơ sở dữ liệu khá lớn với hơn 1800 GB.

Trong đó có một số bảng rất nông (chỉ một vài cột số nguyên) với nhiều triệu hàng. Khi chúng tôi xóa 10.000 hàng từ các bảng nông này, các truy vấn xóa thường khá nhanh (nhiều nhất là một vài giây).

Chúng tôi cũng có một bảng với trường imagelưu trữ hình ảnh trung bình 100 KB. Khi chúng tôi chỉ xóa một vài nghìn hàng khỏi bảng này, sẽ mất hơn một phút.

Mặc dù sự khác biệt là rõ ràng (đã xóa nhiều kích thước dữ liệu hơn), tôi rất muốn tìm hiểu thêm về những gì xảy ra trong SQL Server. Vì vậy, tôi có thể hiểu rõ hơn về việc xóa sau sẽ chậm hơn rất nhiều.

Bất cứ ai có thể xin vui lòng làm sáng tỏ?

nhiều kích thước dữ liệu hơn đã bị xóa

Xóa một imageblob 100kb thực sự không phải là một hoạt động kích thước dữ liệu. Các blob được giải quyết, không bị xóa và không có ghi nhật ký hình ảnh đầy đủ. Bạn có thể dễ dàng kiểm tra điều này:

create database blob
go

use blob
go

create table t (id int not null identity(1,1), blob image)
go

insert into t (blob) values (
  replicate(
    cast(0x000102030405060708090a0b0c0d0e0f as varbinary(max)), 
    100*1024/16))
go 10

alter database blob set recovery full
go

backup database blob to disk='nul:'
go

delete from t where id = 3
go

select * from fn_dblog(null, null)
go

Các bản ghi nhật ký bạn sẽ thấy sẽ là một cái gì đó dọc theo dòng:

00000026:0000008e:0001  LOP_BEGIN_XACT  LCX_NULL    0000:00000304   0x0000  76  124
00000026:0000008e:0002  LOP_LOCK_XACT   LCX_NULL    0000:00000304   0x0000  24  56
00000026:0000008e:0003  LOP_MODIFY_ROW  LCX_PFS     0000:00000304   0x0000  62  92
00000026:0000008e:0004  LOP_HOBT_DELTA  LCX_NULL    0000:00000304   0x0000  64  64
00000026:0000008e:0005  LOP_MODIFY_ROW  LCX_PFS     0000:00000304   0x0000  62  92
00000026:0000008e:0006  LOP_HOBT_DELTA  LCX_NULL    0000:00000304   0x0000  64  64
00000026:0000008e:0007  LOP_MODIFY_ROW  LCX_PFS     0000:00000304   0x0000  62  92
00000026:0000008e:0008  LOP_HOBT_DELTA  LCX_NULL    0000:00000304   0x0000  64  64
00000026:0000008e:0009  LOP_MODIFY_ROW  LCX_PFS     0000:00000304   0x0000  62  92
00000026:0000008e:000a  LOP_HOBT_DELTA  LCX_NULL    0000:00000304   0x0000  64  64
00000026:0000008e:000b  LOP_MODIFY_ROW  LCX_PFS     0000:00000304   0x0000  62  92
00000026:0000008e:000c  LOP_HOBT_DELTA  LCX_NULL    0000:00000304   0x0000  64  64
...    
00000026:0000008e:0022  LOP_HOBT_DELTA  LCX_NULL    0000:00000304   0x0000  64  64
00000026:0000008e:0023  LOP_DELETE_ROWS LCX_TEXT_MIX    0000:00000304   0x0000  62  172
00000026:0000008e:0024  LOP_DELETE_ROWS LCX_HEAP    0000:00000304   0x0000  62  120
00000026:0000008e:0025  LOP_COMMIT_XACT LCX_NULL    0000:00000304   0x0000  80  84

Như bạn có thể thấy, không có bản ghi 'XÓA' với +102400 byte dữ liệu cho hàng chứa imagecột. Có một loạt các thỏa thuận (hoạt động PFS / IAM / GAM) và xóa hàng đơn giản (trong trường hợp của tôi, sẽ trông rất giống với B-Tree mà tôi đã nhớ khi khai báo ID là PK ...). Để biết thêm chi tiết, xem Cách đọc và giải thích nhật ký Máy chủ SQL .

Cái nào mở ra câu hỏi ban đầu: tại sao cái này lại xóa chậm hơn cái kia? Tôi khuyên bạn nên đọc Cách phân tích hiệu suất của SQL Server . Thực hiện theo phương pháp được mô tả để nắm bắt sự chờ đợi cho một tuyên bố cụ thể và xem nguyên nhân là gì. Xem Phân tích thực hiện truy vấn riêng lẻ , đặc biệt là phần Phân tích thời gian chờ thực hiện truy vấn riêng lẻ. Chỉ sau khi bạn đo, chúng tôi mới có thể trả lời câu đố. có thể có nhiều yếu tố: chặn nhiều hơn do đọc đồng thời trên bảng blob, thiếu chỉ mục để xác định các hàng ứng cử viên XÓA trên một bảng, kích hoạt chạy, v.v. Phương pháp được liên kết sẽ giúp bạn xác định nguyên nhân.