THỐNG KÊ IO để quét chỉ mục song song

Giả sử rằng có một bảng với chỉ mục được nhóm

create table [a_table] ([key] binary(900) unique clustered);

và một số dữ liệu

insert into [a_table] ([key])
select top (1000000) row_number() over (order by @@spid)
from sys.all_columns a cross join sys.all_columns b;

Bằng cách kiểm tra số liệu thống kê lưu trữ của bảng này

select st.index_level, page_count = sum(st.page_count)
from sys.dm_db_index_physical_stats(
    db_id(), object_id('a_table'), NULL, NULL, 'DETAILED') st
group by rollup (st.index_level)
order by grouping_id(st.index_level), st.index_level desc;

người ta có thể thấy

index_level page_count
----------- ----------
8           1
7           7
6           30
5           121
4           487
3           1952
2           7812
1           31249
0           125000
NULL        166659

bảng đó mất tổng cộng 166659 trang.

Tuy nhiên quét bảng

set nocount on;
set statistics io, time on;
declare @cnt int;
select @cnt = count(1) from [a_table];
set statistics io, time off;

sản xuất

Table 'a_table'. Scan count 5, logical reads 484367, ...
CPU time = 1757 ms,  elapsed time = 460 ms.

số lần đọc logic cao hơn gần ba lần so với không gian được lấy bởi bảng. Khi tôi kiểm tra kế hoạch truy vấn, tôi nhận thấy rằng SqlServer đã sử dụng quét chỉ mục song song. Và đây là nơi phần đầu tiên của câu hỏi phát sinh.

Làm thế nào quét chỉ mục song song được thực hiện mà làm cho SqlServer thực hiện rất nhiều lần đọc logic?

Chỉ định option (maxdop 1)để triệt tiêu song song

set nocount on;
set statistics io, time on;
declare @cnt2 int;
select @cnt2 = count(1) from [a_table] option (maxdop 1);
set statistics io, time off;

kết quả là

Table 'a_table'. Scan count 1, logical reads 156257, ...
CPU time = 363 ms,  elapsed time = 367 ms.

So sánh thống kê để quét chỉ mục song song và không song song trong trường hợp này dẫn đến một kết luận rằng đôi khi tốt hơn là tránh quét chỉ mục song song. Và đây là nơi phát sinh phần thứ hai của câu hỏi.

Khi nào tôi nên lo lắng về việc quét chỉ mục song song? Khi nào nên tránh / triệt tiêu? Các thực hành tốt nhất là gì?

Các kết quả trên thu được trên

Máy chủ Microsoft SQL 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64)

Nếu bạn thêm một TABLOCKhoặc READUNCOMMITTEDgợi ý vào bảng, bạn sẽ nhận được một lần quét theo thứ tự phân bổ , sẽ báo cáo cùng số lần đọc logic như số trang trong bảng.

Với quét theo thứ tự phân bổ, SQL Server sử dụng các cấu trúc phân bổ để thúc đẩy phân phối các trang giữa các luồng. Truy cập trang IAM không được tính vào STATISTICS IO.

Đối với quét không theo thứ tự phân bổ, SQL Server chia nhỏ quá trình quét thành các phần phụ bằng các khóa chỉ mục. Mỗi thao tác nội bộ để tìm và phân phối một trang mới hoặc một phạm vi trang (dựa trên phạm vi khóa), cho một luồng công nhân yêu cầu truy cập vào các cấp trên của cây b. Các truy cập này được tính theo STATISTICS IO, cũng như các truy cập cấp trên được tạo bởi các luồng công nhân khi định vị điểm bắt đầu của phạm vi hiện tại của chúng. Tất cả các tài khoản đọc cấp trên thêm cho sự khác biệt bạn nhìn thấy.

Theo tôi, quá nhiều trọng lượng được đưa ra cho thống kê I / O. Điều chỉnh các truy vấn của bạn theo những gì quan trọng đối với bạn và khối lượng công việc của bạn. Đây thường là thời gian trôi qua, nhưng việc sử dụng tài nguyên cũng có thể là một yếu tố. Không có một số liệu nào là 'tốt nhất' - bạn nên có một cái nhìn cân bằng.