đọc logic so với số lần quét

Tôi đang tham gia một bảng nhỏ (1.000 hàng) với một bảng lớn (8M hàng) trong SQL Server 2008. Liên kết sử dụng chỉ mục bao phủ không bao gồm trên bảng lớn và phép nối có thể tạo ra ba kế hoạch truy vấn có thể. Tôi đang cố gắng tìm ra kế hoạch nào tốt hơn, nhưng tôi cũng muốn khái quát hóa kiến ​​thức này để lần sau tôi có thể biết rõ hơn phương pháp phỏng đoán sẽ sử dụng khi xem số liệu thống kê I / O của SQL.

Kế hoạch số 1 là tham gia vòng lặp và phát ra số liệu thống kê cho bảng lớn như thế này:

Scan count 2582, logical reads 35686, physical reads 1041, read-ahead reads 23052

Kế hoạch số 2 là một liên kết hợp nhất và phát ra số liệu thống kê như thế này:

Scan count 1, logical reads 59034, physical reads 49, read-ahead reads 59004

Kế hoạch số 3 là một phép nối băm và phát ra số liệu thống kê như thế này:

Scan count 3, logical reads 59011, physical reads 5, read-ahead reads 59010

Các chỉ số bao gồm được sắp xếp theo (ID, Date). Truy vấn trả về dữ liệu cho khoảng 50% ID và, đối với mỗi ID, trả về một đoạn liền kề của 3 tháng gần đây nhất của dữ liệu, thường là khoảng 1/4 hoặc các hàng cho mỗi ID. Truy vấn trả về khoảng 1/8 tổng số hàng trong chỉ mục. Nói cách khác, truy vấn rất thưa thớt nhưng nhất quán là như vậy.

Giả định của tôi là kế hoạch số 1 là khủng khiếp cho khối lượng công việc này, bởi vì việc di chuyển đầu đĩa khoảng 2.500 lần (hoặc thậm chí 1.041 lần) đắt hơn nhiều so với quét đĩa tuần tự. Tôi cũng giả định rằng # 3 và # 2 có các mẫu I / O tương tự, tuần tự (và do đó hiệu quả hơn).

Nhưng có trường hợp nào kế hoạch số 1 thực sự tốt nhất không, trong đó "tốt nhất" có nghĩa là ít ảnh hưởng đến hệ thống con I / O và ít ảnh hưởng đến các truy vấn khác chạy đồng thời?

Hoặc nó thực sự phụ thuộc vào nhiều biến như loại hệ thống con đĩa tôi có, phân mảnh chỉ mục, v.v ... Nếu "nó phụ thuộc" thì có bất kỳ quy tắc nào để tiếp cận vấn đề không?

Đây là thỏa thuận giết người: vào tháng 1, nó đã tiêu tốn 12 nghìn đô la để mua 864 * GB * RAM . Bạn có thể nhận được rất nhiều lợi ích khi chỉ cần tăng RAM của máy chủ lên đến mức bạn sẽ không bao giờ đạt được tốc độ đọc vật lý (dĩ nhiên là sau khi khởi động).

Khác với điều đó thực sự rất khó để đưa ra ý kiến ​​đen hoặc trắng về một trong những điểm dữ liệu mà bạn trình bày. Chắc chắn kế hoạch số 1 có hầu hết các lần đọc vật lý, nhưng bạn có chắc chắn rằng tất cả các thử nghiệm đã được thực hiện trên bộ đệm đã được làm nóng tương tự không? Có thể là # 1 đã làm nóng bộ đệm cho # 2, phương pháp thử nghiệm của bạn là gì để đảm bảo tất cả các trường hợp được xem xét trên mặt đất? Mặc dù vậy, nếu bạn bỏ ra 500 đô la và tăng gấp đôi RAM, liệu nó có còn quan trọng nữa không? # 1 có số lần đọc logic ít nhất ...

Nhưng sau đó # 2 có thể được hưởng lợi từ DOP cao (một lần quét có thể song song). Thời gian đồng hồ treo tường số 2 có tốt hơn số 1 sau khi bạn thêm đủ RAM không?

Có bao nhiêu trong số các kế hoạch chạy song song? Có hàng chục truy vấn yêu cầu đồng thời cấp một bộ nhớ đáng kể cho hàm băm # 3 và do đó tạo ra sự tranh chấp cho RESOURCE_SEMAPHORE? Là số 2 đang thực hiện một loại và cũng yêu cầu cấp bộ nhớ? Số 1 sẽ hoạt động tốt hơn vì nó không yêu cầu tài trợ (ít nhất là từ thông tin được đăng ...)?

Thực sự rất tương đối và câu hỏi bạn đặt ra giống như tìm một giải pháp cho một hệ phương trình phức tạp ... đơn giản là có thể có nhiều hơn một giải pháp đó.

Một điều chắc chắn: 8M hàng phải phù hợp với RAM có nhiều chỗ trống. Những bài đọc vật lý đang cầu xin một số ngân hàng bộ nhớ.

Đối với truy vấn có vẻ rất đơn giản này, trình tối ưu hóa sẽ liên tục tạo ra kế hoạch tốt nhất theo mô hình chi phí của nó. Mô hình chi phí khá chính xác. Vì vậy, đề nghị của tôi sẽ là để lại sự lựa chọn cho SQL Server.

Đề xuất thứ hai: Đo thời lượng truy vấn cho cả ba biến thể với bộ đệm nóng. Rồi hãy quyết định. (Đừng quyết định dựa trên các lần đọc và quét và như vậy. Điều quan trọng với bạn là thời lượng.)

Nói chung, để chọn loại tham gia (hoặc chỉ mục) tốt nhất đòi hỏi phải hiểu về cách thức hoạt động của thuật toán nối. Đó là quá nhiều thông tin để đăng ở đây.

Bỏ qua số lượng quét, nó không quan trọng. Tập trung vào làm thế nào để đọc logic hợp lý. Dựa trên http://www.prrealsqldba.com/2013/07/sql-server-performance-tuning.html .