Bạn có thể giải thích các khái niệm về và mối quan hệ giữa, Bao gồm các chỉ mục và Truy vấn được bảo hiểm trong SQL Server của Microsoft không?Các chỉ mục bao gồm và các truy vấn được bao gồm trong SQL Server là gì?
Chỉ mục bao gồm là chỉ mục bao gồm tất cả các cột được yêu cầu trong truy vấn mà không cần thực hiện thêm tra cứu vào chỉ mục nhóm.
Không có điều gì như truy vấn bao hàm.
Hãy xem bài viết Simple-Talk này: Using Covering Indexes to Improve Query Performance.
Truy vấn bao gồm là nơi tất cả các vị từ có thể được đối sánh bằng cách sử dụng chỉ mục trên các bảng bên dưới.
Đây là bước đầu tiên để cải thiện hiệu suất của sql đang được xem xét.
A truy vấn được bảo hiểm là truy vấn trong đó tất cả các cột trong tập kết quả của truy vấn được lấy từ chỉ mục không được nhóm.
Truy vấn được đưa vào truy vấn được bảo hiểm bằng cách sắp xếp các chỉ mục cẩn thận.
Truy vấn được bảo hiểm thường hoạt động tốt hơn truy vấn không được bao gồm một phần vì chỉ mục không được nhóm có nhiều hàng trên mỗi trang hơn chỉ mục nhóm hoặc chỉ mục heap, vì vậy ít trang hơn cần được đưa vào bộ nhớ để đáp ứng truy vấn. Họ có nhiều hàng hơn trên mỗi trang vì chỉ một phần của hàng trong bảng là một phần của hàng chỉ mục.
A bao gồm chỉ mục là chỉ mục được sử dụng trong truy vấn được bảo vệ. Không có thứ gì như là một chỉ số, trong đó và của chính nó, là một chỉ số bao trùm. Một chỉ số có thể là một chỉ số bao phủ đối với các truy vấn A, trong khi cùng một lúc không phải là một chỉ số bao phủ đối với các truy vấn B.
Vì khía cạnh quan trọng của hiệu suất là "tôi cần mang bao nhiêu trang vào bộ nhớ để trả lại tập kết quả đầy đủ", điều đó có nghĩa là ** truy vấn 'LIMIT 1' không được hưởng lợi từ tối ưu hóa bao quát? ** Trong hầu hết các trường hợp, việc lấy một bản ghi sẽ chỉ yêu cầu một trang đọc (bỏ qua các trường hợp cạnh như lưu trữ ngoài trang hoặc các bảng thực sự rộng). Ngay cả với một truy vấn không được bảo vệ. – Birchlabs
Dưới đây là an article in devx.com nói rằng:
Tạo một chỉ số không clustered có chứa tất cả các cột được sử dụng trong một truy vấn SQL, một kỹ thuật gọi là chỉ số bao gồm
tôi chỉ có thể giả sử rằng một phủ truy vấn là một truy vấn mà có một chỉ số bao gồm tất cả các cột trong bản ghi trả về của nó. Một báo trước - chỉ mục và truy vấn sẽ phải được xây dựng để cho phép máy chủ SQL thực sự suy ra từ truy vấn mà chỉ mục này hữu ích.
Ví dụ, một tham gia của một bảng trên chính nó có thể không được hưởng lợi từ một chỉ số như vậy (tùy thuộc vào trí thông minh của các nhà quy hoạch thực hiện truy vấn SQL):
PersonID ParentID Name
1 NULL Abe
2 NULL Bob
3 1 Carl
4 2 Dave
Giả sử có một chỉ mục trên PersonID,ParentID,Name - đây sẽ là một chỉ số bao phủ cho một truy vấn như:
SELECT PersonID, ParentID, Name FROM MyTable
Nhưng một truy vấn như thế này:
SELECT PersonID, Name FROM MyTable LEFT JOIN MyTable T ON T.PersonID=MyTable.ParentID
Có lẽ sẽ không ích lợi lắm, mặc dù tất cả các cột đều nằm trong chỉ mục. Tại sao?Bởi vì bạn không thực sự nói với nó rằng bạn muốn sử dụng chỉ số ba của PersonID,ParentID,Name.
Thay vào đó, bạn đang xây dựng một điều kiện dựa trên hai cột - PersonID và ParentID (mà lá ra Name) và sau đó bạn đang yêu cầu cho tất cả các hồ sơ, với các cột PersonID, Name. Trên thực tế, tùy thuộc vào việc thực hiện, chỉ mục có thể giúp phần sau. Nhưng đối với phần đầu tiên, bạn nên có các chỉ mục khác.
Nếu tất cả các cột yêu cầu trong select danh sách các truy vấn có sẵn trong chỉ mục, sau đó động cơ truy vấn không nhất thiết phải tra cứu bảng một lần nữa có thể làm tăng đáng kể hiệu suất của truy vấn. Vì tất cả các cột được yêu cầu có sẵn trong chỉ mục, chỉ mục bao gồm truy vấn. Vì vậy, truy vấn được gọi là truy vấn phủ và chỉ mục là chỉ mục bao gồm.
Chỉ mục nhóm có thể luôn bao gồm một truy vấn, nếu các cột trong danh sách chọn từ cùng một bảng.
Các liên kết sau đây có thể hữu ích nếu bạn chưa quen với khái niệm chỉ số:
một chỉ số bao phủ là một trong đó cung cấp cho mỗi cột cần thiết và trong đó Máy chủ SQL không có hop quay lại chỉ mục nhóm để tìm bất kỳ cột nào. Điều này đạt được bằng cách sử dụng chỉ mục không nhóm và sử dụng tùy chọn INCLUDE để bao gồm các cột. Cột không chính có thể chỉ được bao gồm trong các chỉ mục không được nhóm. Không thể xác định các cột trong cả cột khóa và danh sách INCLUDE. Không thể lặp lại tên cột trong danh sách INCLUDE. Các cột không chính có thể được giảm xuống từ một bảng chỉ sau khi chỉ mục không chính được bỏ trước. Please see details here
Khi tôi đơn giản nhớ lại rằng chỉ mục Clustered Index bao gồm danh sách không được sắp xếp theo thứ tự của TẤT CẢ các cột trong bảng đã xác định, đèn bật sáng cho tôi. Từ "cụm", sau đó, đề cập đến thực tế là có một "cụm" của tất cả các cột, giống như một cụm cá trong "điểm nóng" đó. Nếu không có chỉ mục bao gồm cột chứa giá trị tìm kiếm (phía bên phải của phương trình), thì kế hoạch thực hiện sử dụng chỉ mục Clustered Index vào biểu diễn Clustered Index của cột được yêu cầu bởi vì nó không tìm thấy cột được yêu cầu trong bất kỳ trường nào khác "bao gồm" chỉ mục. Việc thiếu sẽ gây ra một toán tử Clustered Index Seek trong Kế hoạch thực hiện được đề xuất, trong đó giá trị tìm kiếm nằm trong một cột bên trong danh sách được sắp xếp được biểu diễn bằng chỉ mục Clustered.
Vì vậy, một giải pháp là tạo một chỉ mục không được nhóm có cột chứa giá trị được yêu cầu bên trong chỉ mục. Theo cách này, không cần tham chiếu đến Clustered Index, và Trình tối ưu hóa sẽ có thể móc chỉ mục đó trong Kế hoạch thực thi mà không có gợi ý. Tuy nhiên, nếu có một Predicate đặt tên cho khóa phân cụm cột duy nhất và một đối số cho một giá trị vô hướng trên khóa phân cụm, Toán tử tìm chỉ mục cụm sẽ vẫn được sử dụng, ngay cả khi đã có chỉ mục bao phủ trên cột thứ hai trong bảng không có chỉ mục.
Chỉ số bao gồm là chỉ mục không được nhóm. Cả hai chỉ mục Clustered và Non-Clustered đều sử dụng B-Trees để cải thiện việc tìm kiếm dữ liệu, sự khác biệt là trong lá của chỉ mục Clustered Index toàn bộ bản ghi (tức là hàng) được lưu trữ ngay tại đây !, nhưng đây không phải là trường hợp Chỉ mục không được nhóm.
Ví dụ: Tôi có một bảng có ba cột: ID, Fname và Lname.
Tuy nhiên, đối với một chỉ số Non-Clustered, có hai khả năng: hoặc bảng đã có một chỉ số Clustered hoặc nó không:
Khi hai sơ đồ hiển thị, các chỉ mục Non-Clustered không cung cấp hiệu suất tốt, bởi vì chúng không thể tìm thấy giá trị yêu thích (tức là Lname) chỉ từ B-Tree. Thay vào đó, họ phải thực hiện thêm một bước Look Up (hoặc là Key hoặc RID) để tìm giá trị của Lname. Và, đây là nơi chỉ mục được bao phủ xuất hiện trên màn hình. Ở đây, chỉ mục Non-Clustered trên ID bao gồm giá trị của Lname ngay bên cạnh nó trong lá của B-Tree và không cần bất kỳ kiểu tra cứu nào nữa.
Cần lưu ý rằng bài viết bạn đã liên kết đề cập đến Truy vấn bao gồm. Chúng xuất hiện để định nghĩa nó như một truy vấn chọn các cột INCLUDEd thành một chỉ mục bao gồm - đó là một chỉ mục không phải là chỉ mục Clustering, có các giá trị cột được lặp lại trong nút lá của nó. Cũng đáng chú ý là một Covering Index có một hình phạt hiệu suất rõ ràng cho INSERT/UPDATE. –
@ChrisMoschini, Sau đó, [truy vấn được bảo vệ] (http://sqlmag.com/database-performance-tuning/covered-query-vs-covering-index) là gì? Giống như bao gồm truy vấn? – Pacerier
@Pacerier Vâng, chúng giống nhau. –