Trong quá trình điều tra một truy vấn chậm, có vẻ như kế hoạch thực hiện đặc biệt không tối ưu (Một vòng lặp lồng nhau thực hiện 9 triệu lần thực hiện tìm kiếm trong đó số lần thực hiện ước tính là 1). Đã xác nhận rằng một số thống kê có liên quan trong đó thực sự lỗi thời tôi đã xây dựng lại các số liệu thống kê và vấn đề hiệu suất được giải quyết một cách hiệu quả.
Cơ sở dữ liệu này có bật Cập nhật thống kê tự động (theo mặc định). Tôi hiểu rằng có một ngưỡng cho các cập nhật thống kê tự động dựa trên việc có 20% + 500 sửa đổi hàng (cập nhật / chèn / xóa). Ngưỡng này dường như đã bị vượt quá một mức độ lớn trên nhiều chỉ mục, do đó có vẻ như (A) có vấn đề với cập nhật tự động hoặc (B) Có nhiều chiến lược cập nhật hơn tôi có thể tìm thấy trên mạng tài liệu.
Tôi đánh giá cao rằng một tác vụ theo lịch trình có thể được thiết lập để cập nhật số liệu thống kê và đây có thể là cách tiếp cận mà chúng tôi thực hiện nếu không tìm thấy giải pháp nào khác, nhưng nó khiến chúng tôi bối rối vì tại sao số lượng sửa đổi lớn như vậy sẽ không kích hoạt tự động cập nhật cho một số thống kê - hiểu lý do tại sao có thể giúp chúng tôi quyết định số liệu thống kê nào cần được cập nhật bởi một tác vụ theo lịch trình.
Một số lưu ý bổ sung:
1) Sự cố đã được ghi nhận trong cơ sở dữ liệu nơi dữ liệu được tạo bằng thử nghiệm tải và do đó một lượng lớn dữ liệu sẽ được thêm vào trong một khoảng thời gian ngắn, do đó, nếu cập nhật tự động xảy ra định kỳ (ví dụ: một lần một ngày tại hầu hết) sau đó điều này có thể giải thích một số hành vi quan sát được. Ngoài ra, các thử nghiệm tải của chúng tôi có xu hướng làm căng thẳng cơ sở dữ liệu rất nhiều, do đó tôi tự hỏi liệu SQL có trì hoãn cập nhật số liệu thống kê trong khi có tải nặng không (và sau đó không cập nhật số liệu thống kê vì một số lý do).
2) Khi cố gắng tạo lại vấn đề này bằng một tập lệnh kiểm tra có chứa các câu lệnh INSERT liên tiếp, CHỌN và XÓA, vấn đề không xảy ra. Tôi tự hỏi liệu sự khác biệt ở đây là mỗi câu lệnh này có ảnh hưởng đến nhiều hàng trên mỗi câu lệnh SQL hay không, trong khi tập lệnh kiểm tra tải của chúng tôi sẽ có xu hướng chèn từng hàng riêng lẻ.
3) DB trong câu hỏi được đặt thành mô hình khôi phục 'Đơn giản'.
Một số liên kết có liên quan:
- Danh sách kiểm tra để phân tích các truy vấn chạy chậm
- Sử dụng số liệu thống kê để cải thiện hiệu suất truy vấn
Tôi cũng đã nêu vấn đề này thông qua kết nối microsoft:
CẬP NHẬT 2011-06-30:
Khi điều tra thêm, tôi tin rằng các số liệu thống kê lỗi thời vượt quá ngưỡng (ví dụ 500 hàng + 20%) là số liệu thống kê không được sử dụng bởi truy vấn sự cố, do đó có thể chúng sẽ được cập nhật khi chạy truy vấn điều đó đòi hỏi họ Đối với các số liệu thống kê được sử dụng bởi truy vấn, chúng đang được cập nhật thường xuyên. Vấn đề còn lại sau đó là các số liệu thống kê này hoàn toàn sai lệch với trình tối ưu hóa kế hoạch truy vấn chỉ sau một vài lần chèn (ví dụ: gây ra 9 triệu đã nói ở trên, trong đó tìm kiếm con số ước tính là 1).
Linh cảm của tôi lúc này là vấn đề liên quan đến sự lựa chọn khóa chính kém, khóa là một mã định danh duy nhất được tạo bằng NEWID () và do đó tạo ra một chỉ mục bị phân mảnh rất nhanh - đặc biệt là yếu tố điền mặc định trong SQL Máy chủ là 100%. Linh cảm của tôi là điều này bằng cách nào đó dẫn đến các số liệu thống kê sai lệch sau khi chèn tương đối ít hàng - ít hơn ngưỡng để tính toán lại các số liệu thống kê. Đây hoàn toàn không phải là vấn đề vì tôi đã tạo ra rất nhiều dữ liệu mà không cần xây dựng lại các chỉ mục một phần, do đó các số liệu thống kê kém có thể là hậu quả của sự phân mảnh chỉ số rất cao. Tôi nghĩ rằng tôi cần thêm các chu trình bảo trì SQL Server vào kiểm tra tải của mình để có ý tưởng tốt hơn về hiệu suất trên một hệ thống thực trong thời gian dài.
CẬP NHẬT 2012-01-10:
Một yếu tố khác để xem xét. Hai cờ theo dõi đã được thêm vào SQL Server 2005 (và dường như vẫn còn tồn tại trong năm 2008) để giải quyết các thiếu sót cụ thể liên quan đến sự xuất hiện của các số liệu thống kê lỗi thời và / hoặc sai lệch. Các cờ trong câu hỏi là:
DBCC TRACEON(2389)
DBCC TRACEON(2390)MSDN: Ian Jose's WebLog: Phím tăng dần và Tự động sửa nhanh Thống kê thống kê trên các cột tăng dần, Fabiano Amorim
Tất nhiên bạn nên rất cẩn thận khi quyết định kích hoạt những lá cờ này vì chúng có thể có tác động bất lợi.