Chỉ số không sử dụng Thực tiễn tốt nhất

Dựa trên truy vấn này, nếu tôi thấy tổng số lần đọc thấp (rất gần với 0 hoặc 0, như 1 hoặc 2) và số lượng cập nhật người dùng cao hoặc vừa phải (tôi không thể tìm thấy chèn hoặc xóa với truy vấn này) với một số lượng lớn hàng, theo lý thuyết tôi nên loại bỏ chỉ số.

SELECT DISTINCT
    OBJECT_NAME(s.[object_id]) AS ObjectName
       , p.rows TableRows
       , i.name AS [INDEX NAME]
       , (user_seeks + user_scans + user_lookups) AS TotalReads
       , user_updates UserUpdates
FROM sys.dm_db_index_usage_stats s
    INNER JOIN sys.indexes i ON i.[object_id] = s.[object_id] 
        AND i.index_id = s.index_id 
    INNER JOIN sys.partitions p ON p.object_id = i.object_id
WHERE OBJECTPROPERTY(s.[object_id],'IsUserTable') = 1
       AND s.database_id = DB_ID()
       AND i.name IS NOT NULL
ORDER BY (user_seeks + user_scans + user_lookups) ASC

Tôi muốn kiểm tra chéo tính chính xác của giả định này ở đây. Ví dụ, một chỉ mục đã tồn tại hơn một năm nhưng chưa bao giờ được đọc, nhưng được cập nhật cao, có vẻ như đó sẽ là một ý tưởng tồi. Có một kịch bản mà giả định này là không hợp lệ?

DMV này chỉ duy trì số liệu thống kê kể từ lần khởi động SQL Server cuối cùng; Chế độ xem bị xóa sạch hoàn toàn và mọi thứ bắt đầu lại từ đầu.

Quan trọng hơn, các hàng trong chế độ xem này cho bất kỳ chỉ mục cụ thể nào sẽ bị xóa khi chỉ mục đó được xây dựng lại (nhưng không phải khi nó được tổ chức lại). Nếu bạn đang thực hiện bảo trì chỉ mục thường xuyên, có thể hữu ích khi xem nhật ký bảo trì và xem liệu có bất kỳ chỉ mục nào bạn đang xem xét giảm có thể được xây dựng lại gần đây không.

Vì vậy, việc đưa ra quyết định dựa trên số lần đọc thấp kể từ lần khởi động lại gần nhất, khi lần khởi động lại cuối cùng có thể là bản vá cập nhật vào thứ ba tuần trước hoặc gói dịch vụ của ngày hôm qua, có thể không sáng suốt. Hoặc khi bạn đang thực hiện bảo trì chỉ mục, kể từ lần xây dựng lại cuối cùng. Có thể có một báo cáo chỉ được chạy một lần một tháng, hoặc một lần một quý, hoặc một lần một năm, và nó được điều hành bởi một người quan trọng và thiếu kiên nhẫn.

Hơn nữa, một chỉ số có thể ở đó cho một cái gì đó sẽ xảy ra trong tương lai mà bạn không biết - một loạt các báo cáo được chuẩn bị cho mùa thuế, giả sử.

Vì vậy, lời khuyên của tôi là:

Sử dụng DMV để xác định các chỉ mục ứng viên cần loại bỏ , nhưng đừng đưa ra quyết định đó trong bong bóng - bạn cần thực hiện công việc để xác định lý do tại sao một chỉ mục có thể tồn tại trước khi thả nó, ngay cả khi nó dường như không được sử dụng .

Yup xem chỉ có số liệu thống kê kể từ lần khởi động lại cuối cùng. Để giúp giảm thiểu việc tôi thiết lập một công việc chạy một truy vấn như công việc bạn đã đăng hàng tháng vào buổi sáng trước khi cửa sổ bảo trì của chúng tôi bắt đầu nắm bắt thông tin mỗi tháng trước khi máy chủ khởi động lại. Điều đó cho phép tôi quay trở lại xa hơn và xem xét các xu hướng theo thời gian. Tôi cũng có một truy vấn thứ hai chạy tìm kiếm các chỉ mục có thể bị thiếu.

Một điều khác cần xem xét là những gì các chỉ số khác trên bảng. Nó có thể không được sử dụng vì nó hầu như hoặc hoàn toàn là một bản sao của chỉ mục khác. Đúng. Máy chủ SQL cho phép bạn tạo hai chỉ mục khác nhau nhưng giống hệt nhau để có thể hoàn toàn dự phòng.

Bạn cũng có thể xem xét kế hoạch truy vấn có thể là gì đối với truy vấn đã sử dụng chỉ mục đó nếu chỉ mục đó bị xóa. Nó sẽ có một chỉ mục khác để sử dụng hay nó có khả năng phải quay lại quét toàn bộ bảng.

Các chỉ mục kết thúc là nhiều nghệ thuật như khoa học bởi vì thực sự rất khó để biết mọi thứ về những gì có thể được chạy và cuối cùng nó thay đổi thường xuyên.