Điều chỉnh hiệu suất truy vấn

Khi bạn viết xong một truy vấn / lưu trữ / hàm, cách thông tin nhất để nhanh chóng nhận được một số tham số hiệu suất là gì? Bạn có chạy truy vấn và xem kế hoạch thực hiện thực tế? Nếu vậy, những thứ bạn tìm kiếm là gì? Rõ ràng quét bảng / chỉ mục là các lần truy cập bit, nhưng những gì khác?

Để đánh giá nhanh, hãy lấy kế hoạch thực hiện ra khỏi SSMS và vào Plan Explorer .

• Xem lại các hoạt động đắt tiền nhất cho bất cứ điều gì bất ngờ. Sắp xếp, bàn làm việc, toán tử nối không phù hợp (ví dụ: vòng lặp lồng nhau nơi bạn mong đợi hợp nhất hoặc băm).
• Nhìn vào số lượng hàng trong từng giai đoạn của kế hoạch, chúng có nằm trong phạm vi bạn dự kiến ​​sẽ thấy không?
• Nhìn vào các hàng ước tính so với thực tế. Nếu thực tế của bạn gần với ước tính, nhiều khả năng bạn có một kế hoạch tốt. Nếu có các biến thể lớn, hãy tìm hiểu lý do tại sao (ví dụ: thiếu và / hoặc thống kê hết hạn).
• Đánh giá tiềm năng cho các vấn đề đánh hơi tham số. Tìm kiếm các khu vực nơi cardinality có thể thay đổi và kiểm tra một loạt các tham số đầu vào.

Có rất nhiều tài liệu tham khảo có sẵn miễn phí ngoài kia, Kế hoạch thực thi máy chủ SQL của Grant Fitchley là một khởi đầu tốt. Tôi cũng thấy các bài đăng trên blog và ebook của Joe Chang về chi phí kế hoạch thực hiện rất hữu ích.

Hầu hết, tất cả những gì tôi làm chỉ là chạy truy vấn và tìm hiểu cách nó thực thi đối với dữ liệu trong thế giới thực. Nếu có vấn đề, thì tôi sẽ xem xét các kế hoạch thực hiện.

Về kế hoạch thực hiện, Brad McGehee có một bài viết thú vị về chủ đề này.

Trong đó anh nói:

Nếu bạn thấy bất kỳ điều nào sau đây trong kế hoạch thực hiện, bạn nên xem xét chúng là dấu hiệu cảnh báo và điều tra chúng về các vấn đề hiệu suất tiềm năng. Mỗi người trong số họ đều kém lý tưởng từ góc độ hiệu suất.

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, don’t include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

Không phải lúc nào cũng có thể tránh được những điều này, nhưng bạn càng có thể tránh chúng, hiệu suất truy vấn sẽ càng nhanh.

SET STATISTICS IO ON

Nói chung, "số lần đọc logic" nên càng thấp càng tốt. Một vài trang được chạm để hoàn thành truy vấn, kế hoạch càng tốt (thường) sẽ nhanh hơn, tác động thấp hơn đến CPU, RAM và IO đĩa.

Điều này sẽ hướng dẫn bạn khi thay đổi các chỉ mục hoặc bao thanh toán lại SQL thực sự hữu ích. Nhìn vào "thời gian thực hiện mili giây" sẽ thay đổi ngay cả với cùng một kế hoạch truy vấn và SQL - các lần đọc logic sẽ phù hợp với mọi kế hoạch truy vấn nhất định.

Ngoài ra "đọc vật lý" phải rất thấp (và bằng 0 và giữ nguyên 0 cho các lần thực hiện tiếp theo). Nếu điều này không làm điều này thì hãy xem việc sử dụng bộ nhớ SQL Server của bạn (tuổi thọ trang, v.v.).