Index_id <256000 có ý nghĩa gì?


11

Trong một hướng dẫn nhất định tôi đọc tác giả đang lọc sys.indexesdựa trên vị ngữ index_id < 256000. Điều này thực hiện được những gì?


2
Có lẽ họ đã sao chép mã từsys.sysindexkeys
Martin Smith

1
@Martin ơi, ôi.
Aaron Bertrand

1
@AaronBertrand - và cũng trong sys.selective_xml_index_paths, sys.xml_indexes, sys.sysindexesnhưng tôi cho rằng những chỉ sẽ được cập nhật nếu các con số kỳ diệu là không còn giá trị.
Martin Smith

1
@Martin Tôi sẽ không đặt cược vào nó. Đặc biệt là cho các quan điểm tương thích ngược. Thật là một cách khủng khiếp để chứng minh làm thế nào để lấy lại siêu dữ liệu ...
Aaron Bertrand

Câu trả lời:


17

Điều này dựa trên quan niệm sai lầm rằng các chỉ mục XML hiện là loại duy nhất có thể có lược đồ id> = 256000 (ít nhất là dựa trên quan sát của chúng; lược đồ này không được ghi lại bằng AFAIK, do đó thậm chí không chắc là nó có chủ ý hay không). Có lẽ tốt trong các phiên bản hiện tại, nhưng ai biết loại chỉ mục nào sẽ được thêm vào tiếp theo và sơ đồ id của nó sẽ bắt đầu ở đâu? Nếu bạn muốn loại trừ các chỉ mục XML, thì bây giờ bạn cũng loại trừ một số thứ khác. Chẳng hạn, các chỉ mục không gian dường như bắt đầu ở id = 384000. Nếu truy vấn ở trên có ý định bao gồm các chỉ mục không gian nhưng không phải là chỉ mục XML, chúng sẽ gây bất ngờ.

Một bộ lọc tốt hơn nhiều sẽ là:

WHERE type <> 3;

... Hoặc thậm chí tốt hơn, vì nó là tài liệu tự ...

WHERE type_desc <> N'XML';

Và bây giờ khi bạn muốn loại trừ, giả sử, các chỉ mục không gian, truy vấn của bạn thay đổi thành ...

WHERE type_desc NOT IN (N'XML', N'SPATIAL');

... thay vì phải tìm ra phạm vi số nào mà các giá trị id cho các chỉ mục không gian có thể chiếm (hoặc không). Chúc may mắn với điều đó.

Đây là những tài liệu khá rõ ràng trong sys.indexes (Transact-SQL) . Tôi thấy không có tài liệu tham khảo nào về con số ma thuật này và tôi khuyên bạn nên chỉ cho tác giả hướng dẫn của bạn ở đây để họ có thể thấy rằng con số ma thuật này không phải là thứ mà họ nên dựa vào (đừng bận tâm dạy người khác dựa vào).


4
+1 đó là một thói quen xấu khủng khiếp. Quên đi index_id. Đặc biệt là vì dữ liệu chính xác hơn để xác định loại đang ngồi ngay bên cạnh ... theo nghĩa đen.
Thomas Stringer

1
Đây có thể là một lỗi thiết kế của SQL Server khi đưa ra index_id với tính thường xuyên này. Chúng nên được chọn ngẫu nhiên để không ai có thể nhầm lẫn dựa vào chúng.
usr

1

Theo cuốn sách "Microsoft SQL Server 2012 Internals" của Kalen Delaney, Craig Freeman, Index_id của chỉ số XML bắt đầu đánh số với 256000. Vì vậy, để có được tất cả thông tin về chỉ mục loại (truy vấn sys.indexes) nhưng bỏ qua các chỉ mục XML bạn có thể đặt bộ lọc như thế.

SELECT * FROM sys.indexes WHERE index_id <256000

Có thể đạt được cùng một tập kết quả bằng cách đặt bộ lọc vào cột loại của sys.indexes. Đối với loại chỉ mục XML type = 3.

SELECT * FROM sys.indexes WHERE type <> 3

hoặc là

cột type_desc cũng có thể được sử dụng.

SELECT * FROM sys.indexes WHERE type_desc <> 'XML'

1
Bạn có tài liệu chính thức cho khiếu nại này?
swasheck

tôi có nó ở đây trang nào? Ngoài ra - tôi tôn trọng những tác giả đó nhưng tôi không chắc đó được coi là "tài liệu chính thức".
swasheck

Đó là một quan sát ngẫu nhiên, tốt nhất, bởi Kalen tại một thời điểm cụ thể, không biết rằng điều này thực sự có chủ ý, không bận tâm đến khả năng nói trong tương lai để xác định liệu một số loại chỉ mục mới sẽ> 256000 trong tương lai. Đây không phải là thứ mà Microsoft dự định dựa vào, đó là lý do tại sao bạn sẽ không tìm thấy bất kỳ tài liệu tham khảo nào trong tài liệu chính thức. Và đồng ý với @swasheck, trong khi cuốn sách đó chắc chắn là một tài nguyên quý giá, nó không phải là tài liệu chính thức.
Aaron Bertrand

3
@swasheck câu hỏi là, tại sao con số 256000 được sử dụng, và không phải cái gì là an toàn. Để thực hành tốt nhất chắc chắn tôi muốn đi cùng Aaron
aasim.abdullah

1
"Điều này thực hiện được những gì?" Về mặt kỹ thuật, câu trả lời sẽ là "không có gì." Về cơ bản, đó là cách mọi người tương quan lọc ra các chỉ mục XML.
swasheck
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.