Chất lượng của một kế hoạch thực thi phụ thuộc nhiều vào độ chính xác của số lượng hàng ước tính của mỗi nhà khai thác kế hoạch. Nếu số lượng hàng ước tính bị lệch đáng kể so với số hàng thực tế, điều này có thể có tác động đáng kể đến chất lượng của kế hoạch thực thi truy vấn. Chất lượng kế hoạch kém có thể là nguyên nhân dẫn đến I / O quá mức, CPU tăng cao, áp lực bộ nhớ, giảm thông lượng và giảm khả năng đồng thời tổng thể.
Theo "chất lượng kế hoạch" - tôi đang nói về việc SQL Server tạo một kế hoạch thực thi dẫn đến các lựa chọn của toán tử vật lý phản ánh trạng thái hiện tại của dữ liệu. Bằng cách đưa ra các quyết định như vậy dựa trên dữ liệu chính xác, có nhiều khả năng là truy vấn sẽ hoạt động đúng cách. Các giá trị ước tính bản số được sử dụng làm đầu vào để tính toán chi phí vận hành và khi các giá trị này quá xa so với thực tế, tác động tiêu cực đến kế hoạch thực thi có thể rõ ràng. Những ước tính này được cung cấp cho các mô hình chi phí khác nhau được liên kết với chính truy vấn và ước tính hàng không hợp lệ có thể ảnh hưởng đến nhiều quyết định khác nhau bao gồm lựa chọn chỉ mục, hoạt động tìm kiếm so với quét, thực hiện song song so với nối tiếp, lựa chọn thuật toán tham gia, kết hợp vật lý bên trong so với bên ngoài lựa chọn (ví dụ:xây dựng so với thăm dò), tạo cuộn chỉ, tra cứu dấu trang so với truy cập bảng đầy đủ theo nhóm hoặc bảng heap, lựa chọn tổng hợp luồng hoặc băm và việc sửa đổi dữ liệu có sử dụng gói rộng hay hẹp hay không.
Ví dụ:giả sử bạn có SELECT sau truy vấn (sử dụng cơ sở dữ liệu Tín dụng):
SELECT m.member_no, m.lastname, p.payment_no, p.payment_dt, p.payment_amt FROM dbo.member AS m INNER JOIN dbo.payment AS p ON m.member_no = p.member_no;
Dựa trên logic truy vấn, sơ đồ sau có phải là hình dạng mà bạn mong đợi sẽ thấy không?
Và kế hoạch thay thế này thì sao, thay vì một vòng lặp lồng nhau, chúng ta có một khớp băm?
Câu trả lời "đúng" phụ thuộc vào một vài yếu tố khác - nhưng một yếu tố chính là số hàng trong mỗi bảng. Trong một số trường hợp, một thuật toán kết hợp vật lý thích hợp hơn thuật toán kia - và nếu các giả định ước tính bản số ban đầu không chính xác, thì truy vấn của bạn có thể đang sử dụng phương pháp không tối ưu.
Nhận dạng các vấn đề ước tính cardinality là tương đối đơn giản. Nếu bạn có một kế hoạch thực thi thực tế, bạn có thể so sánh các giá trị số hàng ước tính với thực tế cho các toán tử và tìm kiếm các độ lệch. SQL Sentry Plan Explorer đơn giản hóa tác vụ này bằng cách cho phép bạn xem các hàng thực tế so với ước tính cho tất cả các toán tử trong một tab cây kế hoạch duy nhất thay vì phải di chuột qua các toán tử riêng lẻ trong sơ đồ đồ họa:
Hiện tại, các sai lệch không phải lúc nào cũng dẫn đến các kế hoạch chất lượng kém, nhưng nếu bạn đang gặp vấn đề về hiệu suất với một truy vấn và bạn thấy các sai lệch như vậy trong kế hoạch, thì đây là một lĩnh vực đáng được nghiên cứu thêm.
Việc xác định các vấn đề ước tính bản số tương đối đơn giản, nhưng cách giải quyết thường không. Có một số nguyên nhân gốc rễ giải thích tại sao các vấn đề về ước tính bản số có thể xảy ra và tôi sẽ đề cập đến mười trong số các lý do phổ biến hơn trong bài đăng này.
Thống kê bị thiếu hoặc cũ
Trong tất cả các lý do dẫn đến các vấn đề về ước tính bản số, đây là lý do mà bạn hy vọng để xem, vì nó thường dễ giải quyết nhất. Trong trường hợp này, số liệu thống kê của bạn bị thiếu hoặc lỗi thời. Bạn có thể đã tắt các tùy chọn cơ sở dữ liệu để tạo và cập nhật thống kê tự động, "không tính toán lại" được bật cho các thống kê cụ thể hoặc có các bảng đủ lớn để cập nhật thống kê tự động của bạn đơn giản là không diễn ra đủ thường xuyên.
Các vấn đề về lấy mẫu
Có thể là độ chính xác của biểu đồ thống kê không đủ - ví dụ:nếu bạn có một bảng rất lớn với dữ liệu sai lệch đáng kể và / hoặc thường xuyên. Bạn có thể cần phải thay đổi lấy mẫu của mình từ mặc định hoặc nếu điều đó không hữu ích - hãy điều tra bằng cách sử dụng các bảng riêng biệt, thống kê được lọc hoặc chỉ mục được lọc.
Mối tương quan giữa các cột ẩn
Trình tối ưu hóa truy vấn giả định rằng các cột trong cùng một bảng là độc lập. Ví dụ:nếu bạn có cột thành phố và tiểu bang, chúng tôi có thể biết trực quan rằng hai cột này có tương quan với nhau, nhưng SQL Server không hiểu điều này trừ khi chúng tôi trợ giúp bằng chỉ mục nhiều cột được liên kết hoặc với nhiều cột được tạo theo cách thủ công thống kê cột. Nếu không giúp trình tối ưu hóa tương quan, tính chọn lọc của các vị từ của bạn có thể bị phóng đại.
Dưới đây là ví dụ về hai vị từ tương quan:
SELECT lastname, firstname FROM dbo.member WHERE city = 'Minneapolis' AND state_prov - 'MN';
Tôi tình cờ biết rằng 10% trong số 10.000 thành viên member của chúng tôi bảng đủ điều kiện cho sự kết hợp này, nhưng trình tối ưu hóa truy vấn đoán rằng đó là 1% trong số 10.000 hàng:
Bây giờ đối chiếu điều này với ước tính thích hợp mà tôi thấy sau khi thêm thống kê nhiều cột:
So sánh cột trong bảng
Các vấn đề ước tính số lượng có thể xảy ra khi so sánh các cột trong cùng một bảng. Đây là một vấn đề được biết đến. Nếu bạn phải làm như vậy, bạn có thể cải thiện ước tính bản số của các so sánh cột bằng cách sử dụng các cột được tính toán thay thế hoặc bằng cách viết lại truy vấn để sử dụng tự nối hoặc các biểu thức bảng phổ biến.
Sử dụng biến bảng
Sử dụng biến bảng nhiều? Các biến bảng hiển thị ước tính số lượng "1" - ước tính chỉ với một số lượng nhỏ hàng có thể không phải là vấn đề, nhưng đối với các tập kết quả lớn hoặc biến động có thể ảnh hưởng đáng kể đến chất lượng kế hoạch truy vấn. Dưới đây là ảnh chụp màn hình ước tính của nhà điều hành về 1 hàng so với 1.600.000 hàng thực tế từ @charge biến bảng:
Nếu đây là nguyên nhân gốc rễ của bạn, bạn nên khám phá các lựa chọn thay thế như bảng tạm thời hoặc bảng dàn cố định nếu có thể.
UDF vô hướng và MSTV
Tương tự như các biến bảng, các hàm vô hướng và giá trị bảng đa câu lệnh là một hộp đen từ quan điểm ước lượng số lượng. Nếu bạn đang gặp phải các vấn đề về chất lượng kế hoạch do chúng, hãy xem xét các hàm trong bảng nội tuyến như một giải pháp thay thế - hoặc thậm chí rút toàn bộ tham chiếu hàm và chỉ tham chiếu trực tiếp đến các đối tượng.
Dưới đây trình bày kế hoạch ước tính so với thực tế khi sử dụng hàm giá trị bảng nhiều câu lệnh:
Các vấn đề về loại dữ liệu
Các vấn đề về kiểu dữ liệu ngầm định kết hợp với các điều kiện tìm kiếm và kết hợp có thể gây ra các vấn đề về ước tính bản số. Chúng cũng có thể lén lút ăn tài nguyên cấp máy chủ (CPU, I / O, bộ nhớ), vì vậy, điều quan trọng là phải xử lý chúng bất cứ khi nào có thể.
Dự đoán phức tạp
Có thể bạn đã thấy mẫu này trước đây - một truy vấn có WHERE mệnh đề có mỗi tham chiếu cột bảng được bao bọc trong các hàm khác nhau, phép toán nối, phép toán và hơn thế nữa. Và mặc dù không phải tất cả các gói chức năng đều loại trừ các ước tính về bản số thích hợp (chẳng hạn như đối với LOWER , UPPER và GETDATE ) có rất nhiều cách để chôn vị ngữ của bạn đến mức trình tối ưu hóa truy vấn không thể đưa ra các ước tính chính xác nữa.
Độ phức tạp của truy vấn
Tương tự như các vị từ bị chôn, các truy vấn của bạn có phức tạp không? Tôi nhận thấy "phức tạp" là một thuật ngữ chủ quan và đánh giá của bạn có thể khác nhau, nhưng hầu hết đều có thể đồng ý rằng lồng các chế độ xem trong các chế độ xem trong các chế độ xem mà tham chiếu các bảng chồng chéo có khả năng không tối ưu - đặc biệt khi được kết hợp với hơn 10 phép nối bảng, tham chiếu hàm và các vị ngữ bị chôn vùi. Mặc dù trình tối ưu hóa truy vấn thực hiện một công việc đáng ngưỡng mộ, nhưng đó không phải là điều kỳ diệu và nếu bạn có sai lệch đáng kể, thì độ phức tạp của truy vấn (truy vấn dao của quân đội Thụy Sĩ) chắc chắn có thể khiến bạn không thể lấy được ước tính hàng chính xác cho các toán tử.
Truy vấn phân tán
Bạn có đang sử dụng các truy vấn phân tán với các máy chủ được liên kết và bạn thấy các vấn đề ước tính bản số đáng kể không? Nếu vậy, hãy đảm bảo kiểm tra các quyền được liên kết với máy chủ chính được liên kết đang được sử dụng để truy cập dữ liệu. Không có db_ddladmin tối thiểu vai trò cơ sở dữ liệu cố định cho tài khoản máy chủ được liên kết, việc thiếu khả năng hiển thị thống kê từ xa do không đủ quyền có thể là nguồn gốc cho các vấn đề ước tính bản số của bạn.
Và còn những người khác…
Có những lý do khác khiến các ước tính về bản số có thể bị sai lệch, nhưng tôi tin rằng tôi đã đề cập đến những lý do phổ biến nhất. Điểm mấu chốt là phải chú ý đến các sai lệch liên quan đến các truy vấn đã biết, hoạt động kém. Đừng cho rằng kế hoạch được tạo dựa trên các điều kiện đếm hàng chính xác. Nếu những con số này bị lệch, trước tiên bạn cần cố gắng khắc phục sự cố này.
