Làm cách nào để biết khi nào nên sử dụng các chỉ mục và loại nào?

Question

Tôi đã tìm kiếm một chút và không thấy bất kỳ câu hỏi tương tự nào, vì vậy ở đây sẽ xảy ra.

Làm cách nào để bạn biết khi nào nên đặt chỉ mục trong bảng? Làm cách nào để bạn quyết định cột nào sẽ bao gồm trong chỉ mục? Khi nào một chỉ số nhóm được sử dụng?

Chỉ mục có thể làm chậm hiệu suất của câu hỏi select không? Có bao nhiêu chỉ mục quá nhiều và bạn cần bao nhiêu bảng để được hưởng lợi từ chỉ mục?

CHỈNH SỬA:

Điều gì về các loại dữ liệu cột? Có thể lập chỉ mục trên varchar hoặc datetime không?

Answer 1

Vâng, câu hỏi đầu tiên là dễ dàng:

Khi một nhóm chỉ số nên được sử dụng?

Luôn. Giai đoạn. Ngoại trừ một số ít trường hợp hiếm gặp. Một chỉ số nhóm làm cho một bảng nhanh hơn, cho mọi hoạt động. VÂNG! Nó có. Xem xuất sắc của Kim Tripp The Clustered Index Debate continues để biết thông tin cơ bản.Cô cũng đề cập đến tiêu chí chính của mình cho một nhóm chỉ số:

• hẹp
• tĩnh (không bao giờ thay đổi)
• độc đáo
• nếu bao giờ có thể: ngày càng

INT SẮC đáp ứng này một cách hoàn hảo - GUID thì không. Xem GUID's as Primary Key để biết thông tin cơ bản mở rộng.

Tại sao thu hẹp? Vì khóa phân cụm được thêm vào mỗi trang chỉ mục của mỗi và mọi chỉ mục không nhóm trên cùng một bảng (để có thể thực sự tra cứu hàng dữ liệu, nếu cần). Bạn không muốn có VARCHAR (200) trong khóa phân cụm của mình ....

Tại sao độc đáo ?? Xem ở trên - khóa phân cụm là mục và cơ chế mà SQL Server sử dụng để tìm duy nhất một hàng dữ liệu. Nó phải là duy nhất. Nếu bạn chọn một khóa phân cụm không duy nhất, bản thân Máy chủ SQL sẽ thêm một bộ định danh 4 byte vào các khóa của bạn. Hãy cẩn thận về điều đó!

Tiếp theo: chỉ mục không được nhóm. Về cơ bản có một quy tắc: bất kỳ khoá ngoại nào trong bảng con tham chiếu đến một bảng khác sẽ được lập chỉ mục, nó sẽ tăng tốc độ JOIN và các hoạt động khác.

Hơn nữa, bất kỳ truy vấn nào có mệnh đề WHERE đều là một ứng cử viên tốt - hãy chọn những ứng dụng đầu tiên được thực thi rất nhiều. Đặt chỉ mục trên các cột hiển thị trong mệnh đề WHERE, trong các câu lệnh ORDER BY.

Tiếp theo: đo hệ thống của bạn, kiểm tra DMV (chế độ xem quản lý động) để biết gợi ý về chỉ mục không sử dụng hoặc bị thiếu và tinh chỉnh hệ thống của bạn lặp đi lặp lại. Đó là một quá trình liên tục, bạn sẽ không bao giờ được thực hiện! Xem here for info trên hai DMV đó (chỉ mục bị thiếu và không sử dụng).

Một từ cảnh báo khác: với một loạt tải chỉ mục, bạn có thể thực hiện bất kỳ truy vấn SELECT nào thực sự thực sự nhanh chóng. Nhưng đồng thời, INSERT, UPDATE và DELETEs phải cập nhật tất cả các chỉ số liên quan có thể bị ảnh hưởng. Nếu bạn chỉ bao giờ SELECT - đi hạt! Nếu không, đó là một hành động cân bằng tốt và tinh tế. Bạn luôn có thể tinh chỉnh một truy vấn đơn lẻ ngoài niềm tin - nhưng phần còn lại của hệ thống của bạn có thể bị ảnh hưởng khi làm như vậy. Không trên chỉ mục cơ sở dữ liệu của bạn! Đặt một vài chỉ số tốt tại chỗ, kiểm tra và quan sát cách hệ thống hoạt động, và sau đó có thể thêm một hoặc hai lần nữa, và một lần nữa: quan sát hiệu suất của toàn bộ hệ thống bị ảnh hưởng như thế nào.

Answer 2

Đây thực sự là một câu hỏi rất có liên quan, mặc dù một nơi bắt đầu tốt sẽ là lập chỉ mục bất kỳ cột nào mà bạn sẽ lọc kết quả. I E. Nếu bạn thường xuyên chia sản phẩm thành các nhóm theo giá bán, hãy lập chỉ mục cột giá bán của bảng sản phẩm để cải thiện thời gian quét cho truy vấn đó, v.v.

Answer 3

Nếu bạn đang truy vấn dựa trên giá trị trong cột, bạn có thể muốn lập chỉ mục cột đó.

tức

SELECT a,b,c FROM MyTable WHERE x = 1 

Bạn muốn một chỉ mục trên X.

Nói chung, tôi thêm chỉ số cho các cột được thường xuyên truy vấn, và tôi thêm chỉ số hợp chất khi tôi truy vấn trên nhiều hơn một cột.

Chỉ mục sẽ không làm tổn thương hiệu suất của lệnh SELECT, nhưng chúng có thể làm chậm INSERTS (hoặc CẬP NHẬT) nếu bạn có quá nhiều cột chỉ mục trên mỗi bảng.

Theo quy tắc chung - hãy bắt đầu bằng cách thêm chỉ mục khi bạn thấy mình nói WHERE a = 123 (trong trường hợp này, chỉ mục cho "a").

Answer 4

Bạn nên sử dụng chỉ mục trên các cột mà bạn sử dụng để chọn và đặt hàng - tức là mệnh đề WHERE và ORDER BY.

Chỉ số có thể làm chậm báo cáo select nếu có nhiều người trong số họ và bạn đang sử dụng WHERE và ORDER BY trên cột chưa được lập chỉ mục.

Đối với kích thước bảng - hàng nghìn hàng và trở lên sẽ bắt đầu hiển thị lợi ích thực sự cho việc sử dụng chỉ mục.

Có nói rằng, có các công cụ tự động để thực hiện việc này và máy chủ SQL có số Database Tuning Advisor sẽ giúp ích cho việc này.

Answer 5

Rule of thumb là khóa chính (ngụ ý và mặc định là cụm) và mỗi cột khóa ngoại

Có nhiều nhưng bạn có thể làm tồi tệ hơn so với sử dụng SQL Server missing index DMVs

Một chỉ số có thể làm chậm một CHỌN nếu người tối ưu hóa đưa ra lựa chọn không tốt và có thể có quá nhiều. Quá nhiều sẽ làm chậm quá trình ghi nhưng cũng có thể chồng chéo các chỉ mục

Answer 6

Trả lời những câu hỏi tôi có thể nói rằng mọi bảng, dù nhỏ, sẽ luôn được hưởng lợi từ ít nhất một chỉ mục vì phải có ít nhất một cách trong đó bạn quan tâm đến việc tìm kiếm dữ liệu; bằng không thì tại sao lưu nó?

Quy tắc chung để thêm chỉ mục sẽ là nếu bạn cần tìm dữ liệu trong bảng bằng cách sử dụng một trường cụ thể hoặc tập hợp các trường.Điều này dẫn đến có bao nhiêu chỉ mục quá nhiều, thường thì càng có nhiều chỉ mục bạn có chèn và cập nhật chậm hơn vì chúng cũng phải sửa đổi các chỉ mục nhưng tất cả phụ thuộc vào cách bạn sử dụng dữ liệu của mình. Nếu bạn cần chèn nhanh thì không sử dụng quá nhiều. Trong báo cáo "chỉ đọc" loại lưu trữ dữ liệu, bạn có thể có một số trong số chúng để làm cho tất cả các tra cứu của bạn nhanh hơn.

Rất tiếc, không có quy tắc nào để hướng dẫn bạn về số hoặc loại chỉ mục để sử dụng, mặc dù trình tối ưu hóa truy vấn của DB bạn đã chọn có thể cung cấp gợi ý dựa trên các truy vấn bạn đang thực hiện.

Đối với chỉ mục nhóm, chúng là thẻ Ace bạn chỉ sử dụng một lần, vì vậy hãy chọn cẩn thận. Bạn nên tính toán độ chọn lọc của trường mà bạn đang nghĩ đến khi đưa nó vào vì nó có thể bị lãng phí để đặt nó vào một thứ gì đó giống như một trường boolean (ví dụ tương ứng) khi tính chọn lọc của dữ liệu rất thấp.