Là phân mảnh mức độ cao là một vấn đề?

DBCC SHOWCONTIG scanning 'MyTable' table...
Table: 'MyTable' (2048062382); index ID: 1, database ID: 28
TABLE level scan performed.
- Pages Scanned................................: 1019182
- Extents Scanned..............................: 127400
- Extent Switches..............................: 127399
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 100.00% [127398:127400]
- Logical Scan Fragmentation ..................: 0.01%
- Extent Scan Fragmentation ...................: 77.25%
- Avg. Bytes Free per Page.....................: 135.7
- Avg. Page Density (full).....................: 98.32%

Tôi đã đọc được rằng Mật độ quét = 100% là rất tốt và Phân đoạn quét logic <1% cũng rất tuyệt. 77% Extent Scan Fragment làm phiền tôi, nhưng internet nói bỏ qua nó.

Tôi đang phân tích một truy vấn thực hiện chậm một bảng. Nó chạy ~ 30 giây trong lần thực hiện đầu tiên, sau đó 200 ms cho lần thực hiện thứ hai và tiếp theo. Tôi có thể thiết lập lại hành vi này với DBCC DROPCLEANBUFFERS.

Là phân mảnh quét mở rộng cao là một đầu mối quan trọng?

(Nếu không, tôi có thể sẽ thêm một câu hỏi khác về truy vấn một bảng của tôi).

Theo kinh nghiệm của tôi, ngay cả khi bạn thực hiện quét toàn bộ bảng, không có khả năng phân mảnh phạm vi sẽ ảnh hưởng nhiều đến hiệu suất và đối với các mẫu truy vấn điển hình hơn thì tốt nhất là không đáng kể. Đó là đối với các truy vấn sử dụng dữ liệu được lưu trong bộ nhớ cache phù hợp với bộ nhớ - rõ ràng sự phân mảnh của bất kỳ loại nào sẽ trở nên khá khó khăn nếu dữ liệu nằm trong bộ nhớ và không được đọc trực tiếp khỏi đĩa.

Bây giờ, bạn đã có một bảng> 8 GB, vì vậy có thể phân mảnh phạm vi có thể gây hại cho các truy vấn của bạn. Nếu truy vấn này đang sử dụng quét bảng trên 34 triệu hàng và điều tồi tệ nhất bạn nhận được (chỉ trong lần thực hiện đầu tiên!) Là 30 giây, thì việc giảm số lượng phân mảnh mức độ đó sẽ giúp ích rất nhiều. 30 giây đó được dành để tải dữ liệu vào bộ nhớ và tôi không thể hiểu rằng việc cải thiện mức độ phân mảnh sẽ mua cho bạn nhiều ở đó. Nếu bạn có bộ nhớ dự phòng để giữ bảng này trong bộ nhớ, có lẽ bạn nên xem xét một công việc khởi động hoặc một số quy trình nền chạy định kỳ truy vấn mà không buộc người dùng phải chờ nó, đảm bảo rằng nó vẫn còn mới trong bộ đệm.

Hekaton có thể là dành cho bạn.

ConstantScan-> NestedLoop-> IndexSeek-> NestedLoop-> Gói KeyLookup

Kế hoạch này đã không truy cập vào toàn bộ bảng vì nó chỉ trả lại 7.000 hàng trong số 34,5M hàng.

Tổng số lượng dữ liệu ra khỏi đĩa là rất nhỏ so với kích thước của toàn bộ bảng ¹ ; tìm kiếm ngẫu nhiên thời gian để thực hiện các hoạt động tra cứu chính dường như chiếm ưu thế. Khắc phục sự cố phân mảnh chỉ áp dụng khi các hoạt động quét có liên quan. Khi mẫu truy cập là ngẫu nhiên giống như ở đây, phân mảnh - và số liệu phân mảnh - không liên quan.

Bạn sẽ có thể xác minh những gì đang diễn ra bằng cách xem hoạt động của đĩa trong Performance Monitor hoặc Resource Monitor trong khi truy vấn đang chạy - Tôi hy vọng bạn sẽ thấy thông lượng đĩa rất thấp.

Giả sử phân tích của tôi là chính xác, đây là một số gợi ý (có thể kết hợp) để cải thiện thời gian thực hiện truy vấn, đặc biệt là với bộ đệm lạnh:

• Đặt (các) tệp dữ liệu trên một hệ thống con lưu trữ có thể xử lý tốt hơn các lần đọc ngẫu nhiên. Theo ước tính sơ bộ, 30s / 7.000 hàng là thời gian tìm kiếm trung bình ~ 4ms, điều này không tệ, vì vậy đây có thể là một đề xuất đắt tiền.

• Sửa đổi chỉ mục không bao gồm để bao gồm truy vấn bằng cách sử dụng INCLUDEcác cột, do đó loại bỏ sự cần thiết phải tra cứu khóa và do đó hầu hết các hoạt động đĩa ngẫu nhiên. Đây có thể là giải pháp tốt nhất, ngay cả khi bạn hy sinh thêm một chút dung lượng lưu trữ cho nó. Hy vọng cái bàn không quá rộng.

_{¹ Giả sử kích thước hàng bằng nhau.}

Ngoài ra, như một bên, DBCC SHOWCONTIGđã bị từ chối trong một thời gian khá lâu - sự thay thế đi về phía trước là sys.dm_db_index_physical_stats.