RID vs INCLUDE trên một lĩnh vực rộng lớn

Tôi có một bảng lưu trữ ghi chú

create tblNote(  
  Id int identity(1,1),  
  ParentId  int ,   
  ParentType varchar(32),   
  NoteType varchar(32),   
  Note varchar(max),  
  CreatedBy varchar(25),   
  CreatedDate  datetime,   
  .  
  .  
  .  
  <other metadata about the note>  
)  

Gần đây tôi đã đọc rất nhiều về cách MSSS xử lý các chỉ mục (2005 và chuyển tiếp).

Tôi có một chỉ mục nhóm trên ID

[Tôi đã cân nhắc việc thay đổi chỉ mục được nhóm thành ParentId, ParentType vì điều đó khá hẹp và nó là tĩnh. ]

Tỷ lệ truy vấn áp đảo đối với bảng này sẽ nằm dọc theo dòng

select NOTE, createdDate, createdBy 
from tblNote 
where parentId = 12 and parentType = 'RFQ'

Câu hỏi tôi muốn hỏi hôm nay (mặc dù mọi phản hồi đều được chào đón) là đây:

Chỉ số NC tôi có thể thêm là:

create index  idx_nc_note_parent(  
        parentId ,   
        parenttype  
    )  
    include (createdby, createdDate)  

Điều này sẽ hữu ích trong việc tạo danh sách nhỏ các ghi chú nơi chúng tôi có thể bao gồm ai và khi nhập thông tin.

Tôi do dự bao gồm một varchar(max)lĩnh vực. Có vẻ như nó thực sự sẽ làm tổn thương số lượng chỉ mục sẽ được lưu trữ (Điều này hợp lý hay không hợp lý)

Giả sử tôi không bao gồm NOTEtrường, Tra cứu RID sẽ cần thiết để thực sự tìm nạp nội dung ghi chú nếu được yêu cầu.

Mặc dù tôi đã đọc khá nhiều về việc tra cứu RID đắt tiền như thế nào, nhưng vẫn phải tốt hơn để có chỉ số này chứ không phải là quét bảng, ĐÚNG?

[xin lỗi về khối mã, tôi đã thêm 4 khoảng trắng, nhưng có lẽ tôi đã làm sai? ]

Vì bạn đã nói rằng hầu hết các truy vấn thường trả về một vài hàng, cho phép truy vấn sử dụng tra cứu RID (tra cứu khóa trong trường hợp này vì bảng có chỉ mục được nhóm) là hoàn toàn tốt để truy xuất trường lớn. Đối với một hệ thống có tính sẵn sàng cao, tôi không thể khuyên bạn nên đặt loại LOB trong một chỉ mục vì điều này ngăn việc xây dựng lại trực tuyến (đối với các phiên bản SQL Server trước năm 2012). Ngoài ra, bạn cần phải rất cẩn thận rằng kế hoạch truy vấn luôn bám sát kế hoạch loại tìm kiếm và không đưa vào quét bảng có thể rất tốn kém. Đây là trường hợp tôi có thể sử dụng gợi ý bảng (hoặc hướng dẫn kế hoạch nếu truy vấn không thể sửa đổi) ngay cả khi không thực sự cần thiết.

Một tùy chọn khác là tạo lại chỉ mục được nhóm trên sự kết hợp parentIdvà parentTypenếu sự kết hợp các giá trị này là tĩnh và thường tăng theo thời gian. Tuy nhiên, sẽ tốt hơn nếu parentTypelà một loại tích phân, và bạn có thể muốn xem xét thay đổi điều đó bằng mọi cách để tiết kiệm không gian lưu trữ nếu bảng cơ sở đang hoặc sẽ trở nên lớn. Xem xét sự thay đổi này cũng liên quan đến việc xem xét nó có thể ảnh hưởng đến việc lập chỉ mục cho các lớp truy vấn khác chạy trên bảng này như thế nào.

Nếu một trong hai phương pháp đó không đủ nhanh cho khối lượng công việc, hãy xem xét triển khai giải pháp lưu trữ dữ liệu bằng cách sử dụng một cái gì đó như AppFoven, quy mô dễ dàng hơn nhiều so với chạy truy vấn SQL mỗi khi bạn cần dữ liệu. Đây có thể là một khoản tiền rất lớn; chi phí được thêm vào phức tạp.

Bạn có thể thử cái này không?

Tạo một chỉ mục trên ParentID và ParentType để tra cứu ID hiện hành ...

Create  NonClustered Index idx_nc_note_parent On tblNote (parentID, parentType)

Tham gia ID trở lại bảng cơ sở để lấy thông tin mong muốn bằng cách sử dụng chỉ mục được nhóm ...

Select  NOTE, createdDate, createdBy
From   (Select  ID
        From    tblNote
        Where   parentID = 12
        And     parentType = 'RFQ') n
Join    tblNote tn
        On  n.ID = tn.ID