Hiểu số liệu thống kê, kế hoạch thực hiện và 'vấn đề chính tăng dần'

Tôi đang cố gắng để hiểu rõ hơn (về mặt khái niệm) mối quan hệ giữa thống kê, kế hoạch thực hiện, thực hiện thủ tục được lưu trữ.

Tôi có đúng không khi nói rằng số liệu thống kê chỉ được sử dụng khi tạo kế hoạch thực hiện cho một thủ tục được lưu trữ và chúng không được sử dụng trong bối cảnh thực thi thực tế? Nói cách khác, nếu điều này là đúng, một khi kế hoạch được tạo ra (và giả sử nó được sử dụng lại đúng cách), thì số liệu thống kê "cập nhật" quan trọng như thế nào?

Tôi đặc biệt bị thúc đẩy bởi một bài báo tôi đọc ( Thống kê, ước tính hàng và cột ngày tăng dần ) mô tả một kịch bản rất giống với kịch bản mà tôi phải đối mặt hàng ngày với một số cơ sở dữ liệu của khách hàng.

Chúng tôi có cột ngày / giờ tăng dần trong một trong những bảng lớn nhất mà chúng tôi truy vấn thường xuyên bằng cách sử dụng một quy trình được lưu trữ cụ thể.

Làm thế nào để bạn ngăn chặn các kế hoạch thực hiện tăng trưởng cũ khi bạn có một trăm ngàn hàng được thêm vào một ngày?

Nếu chúng tôi cập nhật số liệu thống kê thường xuyên để chống lại vấn đề này, liệu có nên sử dụng gợi ý TÙY CHỌN (RECOMPILE) cho truy vấn của thủ tục được lưu trữ này không?

Bất kỳ lời khuyên hoặc khuyến nghị sẽ được đánh giá cao.

Cập nhật : Tôi đang sử dụng SQL Server 2012 (SP1).

Tôi có đúng không khi nói rằng số liệu thống kê chỉ được sử dụng khi tạo kế hoạch thực hiện cho một thủ tục được lưu trữ và chúng không được sử dụng trong bối cảnh thực thi thực tế?

Không, điều xảy ra là kế hoạch thực hiện cho một thủ tục được lưu trữ được lưu trữ. Giả sử có đủ bộ nhớ khả dụng để tiếp tục giữ kế hoạch, nó sẽ không thay đổi trừ khi một trong những điều sau đây xảy ra (từ Bộ nhớ đệm và sử dụng lại kế hoạch thực hiện trong tài liệu SQL Server, nhấn mạnh thêm):

• Các thay đổi được thực hiện đối với bảng hoặc dạng xem được tham chiếu bởi truy vấn (ALTER TABLE và ALTER VIEW).
• Các thay đổi được thực hiện cho một thủ tục duy nhất sẽ loại bỏ tất cả các kế hoạch cho thủ tục đó khỏi bộ đệm (THỦ TỤC THAY ĐỔI).
• Thay đổi đối với bất kỳ chỉ mục được sử dụng bởi kế hoạch thực hiện.
• Cập nhật về số liệu thống kê được sử dụng bởi kế hoạch thực hiện, được tạo rõ ràng từ một câu lệnh, chẳng hạn như CẬP NHẬT THỐNG KÊ, hoặc được tạo tự động.
• Bỏ một chỉ số được sử dụng bởi kế hoạch thực hiện.
• Một cuộc gọi rõ ràng đến sp_recompile.
• Số lượng lớn các thay đổi đối với các khóa (được tạo bởi các câu lệnh INSERT hoặc DELETE từ những người dùng khác sửa đổi bảng được tham chiếu bởi truy vấn).
• Đối với các bảng có kích hoạt, nếu số lượng hàng trong các bảng được chèn hoặc xóa tăng lên đáng kể.
• Thực hiện một thủ tục được lưu trữ bằng cách sử dụng tùy chọn VỚI RECOMPILE.

Vì vậy, nếu số liệu thống kê được cập nhật, kế hoạch lưu trữ sẽ tự động đưa số liệu thống kê mới vào tài khoản và được biên dịch lại.

Làm thế nào để bạn ngăn chặn các kế hoạch thực hiện tăng trưởng cũ khi bạn có một trăm ngàn hàng được thêm vào một ngày?

Một cách là nếu có rất nhiều cập nhật cho bảng, như đã đề cập ở trên. Một vài trăm ngàn hàng thay đổi có thể đáp ứng điều kiện này. Nhưng nếu bạn muốn chắc chắn hoặc có quyền kiểm soát chi tiết hơn: bằng cách cập nhật số liệu thống kê của bạn. Bạn có thể cho phép SQL Server tự động tạo và quản lý số liệu thống kê hoặc tự làm điều đó. Bạn có thể tìm thêm thông tin về một trong hai phương pháp tại SQL Server Auto Update và Auto Tạo tùy chọn thống kê . Khi / nếu bạn thực hiện xây dựng lại các chỉ mục hàng tuần, điều này cũng sẽ kích hoạt các kế hoạch cũng được cập nhật. Thực hiện một số thử nghiệm để xem điều gì có lợi nhất cho bạn, vì việc cập nhật số liệu thống kê quá thường xuyên có thể không mang lại bất kỳ kết quả hiệu suất thực sự nào.

Nếu chúng tôi cập nhật số liệu thống kê thường xuyên để chống lại vấn đề này, liệu có nên sử dụng gợi ý TÙY CHỌN (RECOMPILE) cho truy vấn của thủ tục được lưu trữ này không?

Bạn không cần sử dụng RECOMPILE, vì dựa vào đoạn trích ở trên, bạn có thể thấy rằng kế hoạch thực hiện được cập nhật một cách thích hợp bất cứ khi nào có số liệu thống kê mới. Bạn có thể ổn với cập nhật thống kê cuối ngày (nếu bạn thực sự quan tâm) nhưng tôi không nghĩ đó rõ ràng là một nhu cầu dựa trên những gì bạn đã nói cho đến nay. Tuy nhiên, một lần nữa, tôi sẽ kiểm tra nó để xem điều gì có thể ảnh hưởng đến hiệu suất thủ tục được lưu trữ của bạn và lên kế hoạch phù hợp.

Tôi có đúng không khi nói rằng số liệu thống kê chỉ được sử dụng khi tạo kế hoạch thực hiện

Không, thống kê lỗi thời có thể gây ra sự biên dịch lại liên quan đến sự tối ưu của tuyên bố bị ảnh hưởng.

Chúng tôi có cột ngày / giờ tăng dần trong một trong những bảng lớn nhất mà chúng tôi truy vấn thường xuyên

Các kế hoạch thực hiện dưới tối ưu gây ra bởi các giá trị vị ngữ nằm ngoài (cụ thể ở trên) phạm vi của các giá trị được lưu trữ trong biểu đồ thống kê tương ứng được gọi là Vấn đề chính tăng dần . Xây dựng lại số liệu thống kê là một giải pháp khả thi, nhưng nó có thể khá tốn tài nguyên. Các lựa chọn thay thế bao gồm:

• Cờ dấu vết 2389 và 2390 . Điều này đòi hỏi một chỉ mục tồn tại với cột có vấn đề là khóa hàng đầu. Nó không hoạt động với các bảng được phân đoạn và chỉ hiệu quả trong SQL Server 2014 nếu sử dụng công cụ ước tính cardinality ban đầu. Cờ dấu vết 4139 cũng có thể được yêu cầu nếu đối tượng thống kê là nhãn hiệu cố định.

• Nâng cấp lên SQL Server 2014. Công cụ ước tính cardinality mới bao gồm logic để ước tính ngoài biểu đồ sử dụng thông tin mật độ trung bình. Điều này có thể kém chính xác hơn cờ theo dõi 2389/2390 trong một số trường hợp quan trọng.

• Cho phép cập nhật thống kê tự động thường xuyên hơn cho các bảng lớn có cờ theo dõi 2371 . Với cờ theo dõi này, thay vì cập nhật sau 20% + 500 thay đổi, chỉ cần SQRT(1000 * Table rows)sửa đổi . Đây không phải là một giải pháp hoàn chỉnh như những giải pháp đã đề cập trước đây, vì các bản cập nhật có thể vẫn chưa được kích hoạt đủ thường xuyên.

Nếu nguồn gốc của vấn đề của bạn không phải là quá trình tổng hợp kế hoạch thường xuyên dựa trên các giá trị vị ngữ ngoài biểu đồ, nhưng nhiều hơn về tác động của việc lưu bộ đệm trong một kế hoạch xấu như vậy do kết quả của việc đánh hơi tham số, bạn cũng có thể xem xét:

• Vô hiệu hóa thông số đánh hơi bằng cờ theo dõi 4136
• Sử dụng OPTIMIZE FOR (@parameter = value)để biên dịch một kế hoạch cho một giá trị đại diện đã biết
• Sử dụng OPTIMIZE FOR (@parameter UNKNOWN)để tối ưu hóa bằng cách sử dụng phân phối trung bình
• Sử dụng OPTIMIZE FOR UNKNOWN(giống như 4136, nhưng mỗi truy vấn)
• Sử dụng OPTION (RECOMPILE)để biên dịch mọi lúc, đánh hơi giá trị cụ thể. Nếu phần lớn các giá trị thời gian chạy nằm trong biểu đồ, điều này có thể có hiệu quả.

Để biết thêm thông tin về việc đánh hơi tham số, nhúng và các tùy chọn biên dịch lại, hãy xem bài viết của tôi trên SQLperformance.com.