Cách các chỉ mục được lọc có thể trở thành một tính năng mạnh mẽ hơn

Vì vậy, tại bất kỳ thời điểm nào, chỉ có một giá trị NULL có thể tồn tại trong cột này. Không giống như hầu hết các tình huống, đây là một trường hợp SQL Server coi hai giá trị NULL là bằng nhau (thay vì xác định rằng bằng nhau chỉ đơn giản là không xác định và ngược lại là sai). Nhiều người đã phàn nàn về sự không nhất quán này trong nhiều năm.

Nếu đây là một yêu cầu, bây giờ chúng tôi có thể giải quyết vấn đề này bằng cách sử dụng các chỉ mục đã lọc:

ALTER TABLE dbo.Personnel DROP CONSTRAINT UQ_SSN;
GO
 
CREATE UNIQUE INDEX UQ_SSN ON dbo.Personnel(SSN)
  WHERE SSN IS NOT NULL;

Bây giờ chèn thứ 4 của chúng tôi hoạt động tốt, vì tính duy nhất chỉ được thực thi trên các giá trị không phải NULL. Đây là một kiểu gian lận, nhưng nó đáp ứng các yêu cầu cơ bản mà tiêu chuẩn ANSI dự định (mặc dù SQL Server không cho phép chúng tôi sử dụng ALTER TABLE ... ADD CONSTRAINT cú pháp để tạo một ràng buộc duy nhất đã lọc).

Nhưng, hãy giữ điện thoại

Đây là những ví dụ tuyệt vời về những gì chúng tôi có thể làm với các chỉ mục đã lọc, nhưng có rất nhiều điều chúng tôi vẫn chưa thể làm và kết quả là một số hạn chế và vấn đề phát sinh.

Cập nhật thống kê

Đây là một trong những hạn chế quan trọng hơn IMHO. Các chỉ mục đã lọc không được hưởng lợi từ việc tự động cập nhật thống kê dựa trên phần trăm thay đổi của tập hợp con của bảng được xác định bởi vị từ bộ lọc; nó dựa trên (giống như tất cả các chỉ mục không được lọc) trên toàn bộ bảng. Điều này có nghĩa là, tùy thuộc vào tỷ lệ phần trăm của bảng trong chỉ mục được lọc, số hàng trong chỉ mục có thể tăng gấp bốn lần hoặc giảm một nửa và thống kê sẽ không cập nhật trừ khi bạn làm như vậy theo cách thủ công. Kimberly Tripp đã đưa ra một số thông tin tuyệt vời về điều này (và Gail Shaw trích dẫn một ví dụ trong đó phải mất 257.000 bản cập nhật trước khi số liệu thống kê được cập nhật cho một chỉ mục được lọc chỉ chứa 10.000 hàng):

http://www.sqlskills.com/blogs/kimberly/filtered-indexes-and-filtered-stats-might-become-serious-out-of-date/
http://www.sqlskills.com/ blog / kimberly / category / filter-indexes /

Ngoài ra, đồng nghiệp của Kimberly, Joe Sack (@JosephSack), đã gửi một mục Kết nối đề xuất sửa hành vi này cho cả chỉ mục được lọc và thống kê đã lọc.

Giới hạn biểu thức lọc

Có một số cấu trúc bạn không thể sử dụng trong một vị từ bộ lọc, chẳng hạn như NOT IN , OR và các vị từ động / không xác định như WHERE col >= DATEADD(DAY, -1, GETDATE()) . Ngoài ra, trình tối ưu hóa có thể không nhận ra chỉ mục đã lọc nếu vị từ không khớp chính xác với WHERE mệnh đề trong định nghĩa chỉ mục. Dưới đây là một số mục Connect cố gắng thu hút một số hỗ trợ để có phạm vi phủ sóng tốt hơn tại đây:

Các mục đích sử dụng tiềm năng khác hiện không thể thực hiện được

Chúng tôi hiện không thể tạo chỉ mục được lọc trên một cột được tính toán liên tục, ngay cả khi nó là xác định. Chúng tôi không thể trỏ khóa ngoại vào một chỉ mục được lọc duy nhất; nếu chúng ta muốn một chỉ mục hỗ trợ khóa ngoại ngoài các truy vấn được hỗ trợ bởi chỉ mục được lọc, chúng ta phải tạo một chỉ mục thứ hai, dư thừa, không được lọc. Và đây là một vài hạn chế tương tự khác đã được bỏ qua hoặc chưa được xem xét:

Vấn đề với MERGE

Và MERGE xuất hiện thêm một lần nữa trong danh sách "đề phòng" của tôi:

Mặc dù một trong những lỗi này (có vẻ liên quan mật thiết) nói rằng nó đã được sửa trong SQL Server 2012, bạn có thể cần liên hệ với PSS nếu bạn gặp phải bất kỳ biến thể nào của vấn đề này, đặc biệt là trên các phiên bản trước đó (hoặc ngừng sử dụng MERGE , như tôi đã đề xuất trước đây).

Giới hạn của công cụ / DMV / tích hợp sẵn

Có nhiều DMV, lệnh DBCC, thủ tục hệ thống và công cụ máy khách mà chúng ta bắt đầu dựa vào theo thời gian. Tuy nhiên, không phải tất cả những thứ này đều được cập nhật để tận dụng các tính năng mới; các chỉ mục được lọc cũng không ngoại lệ. Các mục Connect sau đây chỉ ra một số vấn đề có thể khiến bạn gặp khó khăn nếu bạn muốn chúng hoạt động với các chỉ mục đã lọc:

Đối với ba phần cuối cùng, đừng nín thở - Microsoft không có khả năng đầu tư bất kỳ thời gian nào vào các quy trình sp_, DMV, chế độ xem INFORMATION_SCHEMA, v.v. Thay vào đó, hãy xem các bản viết lại sp_helpindex của Kimberly Tripp, bao gồm thông tin về các chỉ mục được lọc cùng với các tính năng mới khác mà Microsoft đã để lại.

Hạn chế của Trình tối ưu hóa

Có một số mục Kết nối mô tả các trường hợp mà chỉ mục đã lọc * có thể * được trình tối ưu hóa sử dụng, nhưng thay vào đó bị bỏ qua. Trong một số trường hợp, chúng không được coi là "lỗi" mà là "lỗ hổng trong chức năng"…

Paul White (@SQL_Kiwi) gần đây đã đăng ở đây trên SQLPerformance.com một bài đăng đi sâu vào chi tiết về một số hạn chế của trình tối ưu hóa ở trên.

Và Tim Chapman đã viết một bài đăng tuyệt vời nêu ra một số hạn chế khác của các chỉ mục được lọc - chẳng hạn như không thể so khớp vị từ với một biến cục bộ (đã được sửa vào năm 2008 R2 SP1) và không thể chỉ định một chỉ mục được lọc trong một gợi ý chỉ mục.

Kết luận

Các chỉ mục đã lọc có tiềm năng rất lớn và tôi đã rất kỳ vọng vào chúng khi chúng được giới thiệu lần đầu tiên trong SQL Server 2008. Tuy nhiên, hầu hết các hạn chế xuất hiện với phiên bản đầu tiên của chúng vẫn tồn tại cho đến ngày nay, một phần rưỡi (hoặc hai, tùy thuộc vào bạn. quan điểm) các bản phát hành chính sau này. Ở trên có vẻ giống như một danh sách giặt là khá phong phú về các hạng mục cần được giải quyết, nhưng tôi không có ý cho nó đi theo cách đó. Tôi chỉ muốn mọi người nhận thức được rất nhiều vấn đề tiềm ẩn mà họ có thể cần xem xét khi tận dụng các chỉ mục đã lọc.