Quét đơn hàng phân bổ

Khi kế hoạch thực thi bao gồm quá trình quét cấu trúc chỉ mục b-tree, công cụ lưu trữ có thể có thể chọn giữa hai chiến lược truy cập vật lý khi kế hoạch được thực thi:

1. Tuân theo cấu trúc b-cây chỉ mục; hoặc,
2. định vị các trang bằng cách sử dụng thông tin phân bổ trang nội bộ.

Khi có sự lựa chọn, công cụ lưu trữ sẽ đưa ra quyết định về thời gian chạy cho mỗi lần thực thi. Bản tổng hợp lại kế hoạch không cần thiết để nó thay đổi ý định.

Chiến lược cây b bắt đầu từ gốc của cây, đi xuống đến mép cực của mức lá (tùy thuộc vào việc quét tiến hay lùi), sau đó đi theo các liên kết trang cấp lá cho đến khi đạt đến đầu kia của chỉ mục . Chiến lược phân bổ sử dụng cấu trúc Bản đồ phân bổ chỉ mục (IAM) để định vị các trang cơ sở dữ liệu được phân bổ cho chỉ mục. Mỗi trang IAM ánh xạ phân bổ đến khoảng 4GB trong một tệp cơ sở dữ liệu vật lý, vì vậy việc quét chuỗi IAM được liên kết với chỉ mục có xu hướng truy cập các trang chỉ mục theo thứ tự tệp vật lý (ít nhất là theo như SQL Server có thể cho biết).

Sự khác biệt chính giữa hai chiến lược là:

1. Quét b-tree có thể phân phối các hàng tới bộ xử lý truy vấn theo thứ tự khóa chỉ mục; không thể quét theo hướng IAM;
2. quá trình quét b-tree có thể không đưa ra các yêu cầu I / O đọc trước lớn nếu các trang chỉ mục tiếp giáp về mặt logic cũng không tiếp giáp về mặt vật lý (ví dụ:do kết quả của việc tách trang trong chỉ mục).

Quét b-tree luôn có sẵn cho một chỉ mục. Các điều kiện thường được trích dẫn để có sẵn các bản quét thứ tự phân bổ là:

1. Kế hoạch truy vấn phải cho phép quét chỉ mục không theo thứ tự;
2. chỉ mục phải có kích thước ít nhất là 64 trang; và,
3. hoặc là TABLOCK hoặc NOLOCK gợi ý phải được chỉ định.

Điều kiện đầu tiên đơn giản có nghĩa là trình tối ưu hóa truy vấn phải đánh dấu quá trình quét bằng Ordered:False bất động sản. Đánh dấu quét Ordered:False có nghĩa là kết quả chính xác từ kế hoạch thực thi không yêu cầu quét để trả về các hàng theo thứ tự khóa chỉ mục (mặc dù nó có thể làm như vậy nếu thuận tiện hoặc cần thiết).

Điều kiện thứ hai (kích thước) chỉ áp dụng cho SQL Server 2005 trở lên. Nó phản ánh thực tế là có một khoản chi phí khởi động nhất định để thực hiện quét theo hướng IAM, vì vậy cần có số trang tối thiểu để có thể tiết kiệm được để hoàn trả khoản đầu tư ban đầu. “64 trang” đề cập đến giá trị của data_pages cho IN_ROW_DATA chỉ đơn vị phân bổ, như được báo cáo trong sys.allocation_units.

Tất nhiên, chỉ có thể có lợi nhuận từ việc quét đơn đặt hàng phân bổ nếu việc cân nhắc đọc trước có thể lớn hơn thực sự đi vào hoạt động, nhưng SQL Server hiện không xem xét yếu tố này. Đặc biệt, nó không tính đến lượng chỉ mục hiện đang ở trong bộ nhớ, cũng như không quan tâm đến mức độ phân mảnh của chỉ mục.

Điều kiện thứ ba có lẽ là mô tả ít hoàn chỉnh nhất trong danh sách. Trên thực tế, gợi ý không bắt buộc , mặc dù chúng có thể được sử dụng để đáp ứng các yêu cầu thực tế:Dữ liệu phải được đảm bảo không thay đổi trong quá trình quét hoặc (gây tranh cãi hơn), chúng tôi phải chỉ ra rằng chúng tôi không quan tâm về các kết quả có khả năng không chính xác, bằng cách thực hiện quét ở mức cách ly không cam kết đã đọc.

Ngay cả với những giải thích rõ ràng này, danh sách các điều kiện để quét theo thứ tự phân bổ vẫn chưa hoàn chỉnh. Có một số lưu ý và ngoại lệ quan trọng mà chúng ta sẽ trình bày ngay sau đây.

Bản trình diễn

Truy vấn sau sử dụng cơ sở dữ liệu mẫu AdventureWorks:

 CHECKPOINT; DBCC DROPCLEANBUFFERS; GOSELECT P.BusinessEntityID, P.PersonTypeFROM Person.Person AS P; 

Lưu ý rằng bảng Person chứa 3.869 trang. Kế hoạch hậu thực thi (thực tế) như sau (được hiển thị trong SQL Sentry Plan Explorer):

Về các yêu cầu quét thứ tự phân bổ, chúng tôi có cho đến nay:

• Kế hoạch có Ordered:False bất động sản; và,
• bảng có hơn 64 trang; nhưng,
• chúng tôi đã không làm gì để đảm bảo dữ liệu không thể thay đổi trong quá trình quét. Giả sử phiên của chúng tôi đang sử dụng cam kết đã đọc mặc định mức cô lập, quá trình quét không được thực hiện ở đã đọc không cam kết mức độ cô lập.

Do đó, chúng tôi mong đợi quá trình quét này được thực hiện bằng cách quét cây b thay vì theo hướng IAM. Kết quả truy vấn cho thấy điều này có thể đúng:

Các hàng được trả về theo thứ tự khóa Chỉ mục cụm (bởi BusinessEntityID ). Tôi phải nói rõ rằng thứ tự kết quả này hoàn toàn không được đảm bảo , và không nên dựa vào. Các kết quả có thứ tự chỉ được đảm bảo bởi một ORDER BY cấp cao nhất thích hợp mệnh đề.

Tuy nhiên, thứ tự đầu ra quan sát được là bằng chứng ngẫu nhiên cho thấy quá trình quét được thực hiện lần này bằng cách tuân theo cấu trúc cây b-chỉ mục được phân cụm. Nếu cần thêm bằng chứng, chúng tôi có thể đính kèm trình gỡ lỗi và xem đường dẫn mã SQL Server đang thực thi trong quá trình quét:

Ngăn xếp cuộc gọi hiển thị rõ ràng quá trình quét theo cây b.

Thêm gợi ý khóa bảng

Bây giờ chúng tôi sửa đổi truy vấn để bao gồm gợi ý khóa bảng:

 CHECKPOINT; DBCC DROPCLEANBUFFERS; CHỌN P.BusinessEntityID, P.PersonTypeFROM Person.Person AS P VỚI (TABLOCK); 

Ở cấp độ cách ly đã cam kết đọc khóa mặc định, khóa cấp bảng được chia sẻ ngăn chặn bất kỳ sửa đổi đồng thời nào có thể xảy ra đối với dữ liệu. Với tất cả ba điều kiện tiên quyết để quét theo hướng IAM được đáp ứng, bây giờ chúng tôi mong đợi SQL Server sử dụng quét theo thứ tự cấp phát. Kế hoạch thực hiện vẫn giống như trước, vì vậy tôi sẽ không lặp lại nó, nhưng kết quả truy vấn chắc chắn trông khác:

Các kết quả dường như vẫn được sắp xếp theo thứ tự của BusinessEntityID , nhưng điểm xuất phát (10866) thì khác. Thật vậy, nếu chúng ta cuộn xuống kết quả, chúng ta sẽ sớm gặp các phần rõ ràng là không có thứ tự quan trọng:

Thứ tự một phần là do quá trình quét thứ tự phân bổ xử lý toàn bộ trang chỉ mục tại một thời điểm. Kết quả trong một trang tình cờ được trả về theo thứ tự của khóa chỉ mục, nhưng thứ tự của các trang được quét giờ đã khác. Một lần nữa, tôi nên nhấn mạnh rằng kết quả có thể khác với bạn:không có gì đảm bảo về thứ tự đầu ra, ngay cả trong một trang, mà không có ORDER BY cấp cao nhất trên truy vấn ban đầu.

Để so sánh với ngăn xếp cuộc gọi được hiển thị trước đó, đây là dấu vết ngăn xếp thu được trong khi Máy chủ SQL đang xử lý truy vấn với TABLOCK gợi ý:

Tiến xa hơn một chút trong quá trình thực hiện:

Rõ ràng, SQL Server đang thực hiện quét theo thứ tự cấp phát khi khóa bảng được chỉ định. Thật đáng tiếc là không có dấu hiệu nào trong kế hoạch sau thực thi về loại quét nào đã được sử dụng trong thời gian chạy. Xin nhắc lại, kiểu quét do công cụ lưu trữ chọn và có thể thay đổi giữa các lần thực hiện mà không cần biên dịch lại kế hoạch.

Các cách khác để đáp ứng điều kiện thứ ba

Tôi đã nói trước đó để có được một quá trình quét theo hướng IAM, chúng ta cần đảm bảo dữ liệu không thể thay đổi bên dưới quá trình quét trong khi nó đang diễn ra, hoặc chúng ta cần chạy truy vấn ở mức cách ly không cam kết đã đọc. Chúng tôi đã thấy rằng gợi ý khóa bảng khi khóa cách ly cam kết đã đọc là đủ để đáp ứng yêu cầu đầu tiên trong số các yêu cầu đó và dễ dàng cho thấy rằng việc sử dụng NOLOCK/READUNCOMMITTED gợi ý cũng cho phép quét thứ tự phân bổ với truy vấn demo.

Trên thực tế, có nhiều cách để đáp ứng điều kiện thứ ba, bao gồm:

• Thay đổi chỉ mục để chỉ cho phép khóa bảng;
• làm cho cơ sở dữ liệu ở chế độ chỉ đọc (vì vậy dữ liệu được đảm bảo không thay đổi); hoặc,
• thay đổi phiên mức cô lập thành READ UNCOMMITTED .

Tuy nhiên, có nhiều biến thể thú vị hơn về chủ đề này có nghĩa là chúng tôi cần sửa đổi ba điều kiện đã nêu trước đây…

Các mức cách ly của lập phiên bản hàng

Bật tính năng cô lập ảnh chụp nhanh đã cam kết đã đọc (RCSI) trên cơ sở dữ liệu AdventureWorks và chạy thử nghiệm với TABLOCK gợi ý một lần nữa (tại đọc cam kết cách ly):

 CHECKPOINT; DBCC DROPCLEANBUFFERS; GOSELECT P.BusinessEntityID, P.PersonTypeFROM Person.Person AS P TABLESAMPLE SYSTEM (50 ROWS) REPEATABLE (12345678) --WITH (TABLOCK); 

 CHỌN ĐẦU (5) P.BusinessEntityID, P.PersonTypeFROM Person.Person AS P VỚI (TABLOCK) ĐẶT ROWCOUNT 5; CHỌN P.BusinessEntityID, P.PersonTypeFROM Person.Person AS P VỚI (TABLOCK) ĐẶT ROWCOUNT 0; 

 CHECKPOINT; DBCC DROPCLEANBUFFERS; ĐI - CẢNH BÁO! Tắt tính năng quét theo thứ tự phân bổ trên phạm vi rộngEXECUTE sys.sp_configure @configname ='ngưỡng con trỏ', @configvalue =5000; TÁI HÌNH VỚI OVERRIDE; ĐI - Thông thường sẽ dẫn đến việc quét theo thứ tự phân bổ. ngưỡng con trỏ ', @configvalue =-1; CẤU HÌNH LẠI VỚI BÊN NGOÀI;