SQL không tham gia song song cho truy vấn cực lớn

Tôi có một truy vấn rất lớn (~ 630 dòng) liên quan đến rất nhiều SELECTcâu lệnh lồng nhau và lấy từ nhiều khung nhìn. Máy chủ SQL của chúng tôi có chế độ song song được đặt thành 2 với ngưỡng 95 (đặt theo cách đó vì DBA của chúng tôi đã tối ưu hóa nó dựa trên một số ứng dụng khác). Truy vấn này gần đây đã bắt đầu mất 5-10 phút để hoàn thành, tăng từ thường ít hơn một phút. Trong khi điều tra nguyên nhân, chúng tôi nhận thấy rằng nó dường như không bao giờ kích hoạt song song, luôn chạy nối tiếp và nghi ngờ rằng có thể có liên quan đến hiệu suất của nó. Điều kỳ lạ là trong khi thử nghiệm, chúng tôi thậm chí đã giảm ngưỡng xuống giá trị mặc định là 5 giây và nó vẫn không chạy song song. Điều gì có thể ngăn chặn nó?

Chúng tôi đã thực hiện thử nghiệm trên một môi trường phi sản xuất mà không ai khác đang sử dụng vào thời điểm đó, vì vậy đây là truy vấn duy nhất đang được chạy. DBA của chúng tôi cũng đã thử những thứ như xóa bộ nhớ cache và kế hoạch, và thậm chí tái chế hệ thống, nhưng nó không có hiệu quả.

Cập nhật 1 : Mỗi bình luận, tôi đã xác minh rằng số liệu thống kê được cập nhật hàng đêm nhưng vấn đề vẫn còn. Chúng tôi thực sự đã đưa mã trở lại phiên bản trước đó không có vấn đề nghiêm trọng về hiệu năng như vậy, nhưng sẽ tiếp tục kiểm tra mã này vì nó được cho là cải thiện hiệu suất so với mã cũ và thực sự đã làm trong thử nghiệm ban đầu. Sẽ cập nhật tại đây cho phù hợp.

Điều kỳ lạ là trong khi thử nghiệm, chúng tôi thậm chí đã giảm ngưỡng xuống giá trị mặc định là 5 giây và nó vẫn không chạy song song. Điều gì có thể ngăn chặn nó?

Có nhiều lý do mà trình tối ưu hóa sẽ không (hoặc không thể) tạo ra một kế hoạch song song. Rộng rãi:

1. Các nguyên nhân rõ ràng, chẳng hạn như cài đặt cấu hình mức độ song song tối đa được đặt thành một, chạy trong nhóm tải công việc của Thống đốc tài nguyên với MAX_DOP = 1hoặc chỉ có một bộ xử lý logic có sẵn cho SQL Server

2. Hoạt động ức chế song song

   Có nhiều hoạt động ngăn chặn sự song song, vì chúng không có ý nghĩa trong kế hoạch song song hoặc do sản phẩm không hỗ trợ chúng (chưa). Một số ví dụ (không đầy đủ!) Về những điều buộc toàn bộ kế hoạch phải nối tiếp:

   • Sửa đổi nội dung của một biến bảng (đọc là tốt)
   • Bất kỳ hàm vô hướng T-SQL nào (dù sao cũng xấu)
   • Các hàm vô hướng CLR được đánh dấu là thực hiện truy cập dữ liệu (các hàm bình thường vẫn ổn)
   • Một số chức năng nội tại bao gồm OBJECT_NAME, ENCYPTBYCERTvàIDENT_CURRENT
   • Con trỏ chuyển tiếp nhanh
   • Truy cập bảng hệ thống (ví dụ: sys.tables )
     
     

   Mọi tham chiếu đến một bảng (hoặc dạng xem) với cột được tính toán sử dụng hàm vô hướng T-SQL không nội tuyến sẽ dẫn đến một kế hoạch nối tiếp, ngay cả khi cột đó không được tham chiếu trong truy vấn .

3. Lỗi ước tính cardinality

   Nếu không có gì ngăn chặn tuyệt đối sự song song trong truy vấn đích, trình tối ưu hóa vẫn có thể chọn phương án thay thế nối tiếp nếu nó có chi phí ước tính thấp hơn . Điều này có thể được gây ra bởi ước tính cardinality không chính xác.

4. Chi phí hạn chế mô hình

   SQL Server sử dụng một mô hình để ước tính chi phí thời gian chạy của mỗi toán tử trong một kế hoạch truy vấn. Mô hình này có thể không chính xác chi phí một kế hoạch nối tiếp rẻ hơn so với thay thế song song. Trình tối ưu hóa luôn chọn tùy chọn có vẻ rẻ nhất mà nó xem xét.

   Khi SQL Server chi phí một kế hoạch song song, nó thường giảm chi phí CPU cho trình lặp song song theo hệ số bằng với DOP thời gian chạy dự kiến. Các kế hoạch với các phép nối Nested Loops có thể là một vấn đề đặc biệt, bởi vì bên trong hầu như luôn luôn chạy nhiều luồng. Các biểu tượng song song vẫn còn, nhưng chúng chỉ ra rằng có các chuỗi nối tiếp độc lập DOP.

   Sự khác biệt có lẽ là một sự tinh tế, nhưng nó (a) giải thích tại sao các toán tử thường buộc một vùng nối tiếp có thể chạy "song song" ở phía bên trong của một vòng lặp; và (b) trình tối ưu hóa không làm giảm chi phí CPU ở phía bên trong bằng DOP thời gian chạy ước tính. Điều này đặt các vòng lặp lồng nhau vào thế bất lợi khi tính chi phí song song, so với Hash và Merge Joins, và có thể giải thích tại sao trình tối ưu hóa có thể không chọn kế hoạch Vòng lặp lồng song song.

5. Vấn đề đường dẫn mã tối ưu hóa

   Trình tối ưu hóa có thể không đi xa đến mức đánh giá một kế hoạch song song. Một cách điều này có thể xảy ra là nếu kế hoạch cuối cùng được tìm thấy trong giai đoạn Kế hoạch tầm thường. Nếu Kế hoạch tầm thường là có thể và chi phí kết quả thấp hơn ngưỡng chi phí được cấu hình cho song song, các giai đoạn tối ưu hóa đầy đủ sẽ bị bỏ qua và một kế hoạch nối tiếp được trả lại ngay lập tức.

   Các truy vấn vượt qua Kế hoạch tầm thường vẫn có thể chấm dứt tối ưu hóa sớm (trước khi xem xét tính song song), với thông báo Tìm thấy kế hoạch đủ tốt hoặc hết thời gian . Cả hai đều là phương pháp phỏng đoán để ngăn chặn trình tối ưu hóa dành nhiều thời gian tối ưu hóa hơn mức tăng để đạt được bằng cách giảm thời gian thực hiện ước tính (chi phí).

Kiểm tra

Không có cách nào được hỗ trợ để yêu cầu một kế hoạch song song nhưng có một vài thủ thuật không có giấy tờ (không phù hợp với sản xuất). Một là đặt tạm thời trọng số CPU được sử dụng trong quá trình tối ưu hóa cao hơn và thứ hai là đặt cờ theo dõi 8649. Đối với SQL Server 2016 SP1 CU2 trở lên, gợi ý truy vấn không có tài liệu OPTION (USE HINT ('ENABLE_PARALLEL_PLAN_PREFERENCE'))thực hiện chức năng tương tự như TF 8649, nhưng không cần quyền quản trị viên.

Kế hoạch được tạo ra có thể không phải là một trình tối ưu hóa thường xem xét, nhưng bạn có thể nắm bắt và sử dụng nó trong hướng dẫn kế hoạch trong sản xuất sau khi kiểm tra và xem xét cẩn thận.

Để biết thêm thông tin, hãy xem bài viết của tôi Buộc Kế hoạch thực hiện truy vấn song song và các hoạt động không song song trong SQL Server của Simon Sabin.