Tôi có thể tìm thấy một số hướng dẫn về chiến lược chỉ số ở đâu?


22

Hầu hết chúng ta có thể sẽ đồng ý rằng sử dụng các chỉ mục cơ sở dữ liệu là tốt. Quá nhiều chỉ số và hiệu suất thực sự có thể bị suy giảm.

Theo nguyên tắc chung, trường nào nên được lập chỉ mục?
Những lĩnh vực nào không nên được lập chỉ mục?
Các quy tắc để sử dụng các chỉ mục trong khi tạo ra sự cân bằng giữa quá nhiều và không đủ chỉ mục để đạt được cải thiện hiệu suất, không suy giảm?


7
Để được hướng dẫn về lập chỉ mục, hãy sử dụng
Mike Sherrill 'Cat Recall'

Câu trả lời:


24

Ngắn

Quy tắc "quá nhiều chỉ mục" là một chút sai lầm tôi nghĩ.

Dài

Cho rằng cơ sở dữ liệu trung bình là khoảng 98% số lần đọc (hoặc cao hơn) các lần đọc cần phải được tối ưu hóa. Ví dụ, một INSERT là một chỉ số nếu có một chỉ mục duy nhất. Hoặc WHERE trên một bản cập nhật. Tôi đã từng đọc rằng ngay cả một cơ sở dữ liệu chuyên sâu viết vẫn còn 85% đọc.

Những gì bạn có là lập chỉ mục chất lượng kém. Ví dụ:

  • chỉ mục cụm rộng (đặc biệt là SQL Server)
  • cụm không đơn điệu được lập chỉ mục
  • các chỉ mục chồng chéo (ví dụ cold, colecold, cole, colf)
  • nhiều chỉ mục cột đơn (cũng trùng lặp với các chỉ mục hữu ích hơn) vô dụng cho các truy vấn của bạn
  • không có INCLUDE, không bao gồm (ví dụ: tất cả các chỉ mục cột đơn)
  • ...

Lưu ý khá phổ biến khi có các chỉ mục lớn hơn nhiều lần so với dữ liệu thực tế của bạn ngay cả trong các hệ thống OLTP.

Nói chung, tôi bắt đầu với

  • chỉ số cụm (thường là PK)
  • các chỉ mục duy nhất (không ràng buộc, chúng không thể bao gồm)
  • cột khóa ngoại

Sau đó, tôi sẽ xem xét:

  • truy vấn phổ biến và xem những gì tôi cần. Một truy vấn chạy mỗi giây cần điều chỉnh. Báo cáo vào Chủ nhật 4 giờ sáng có thể chờ.
  • với SQL Server, các DMV chỉ mục bị thiếu trọng số

Nói rằng, tôi đã phá vỡ các quy tắc này cho một số hệ thống sau khi thấy cách mọi thứ mở ra (10 tỷ hàng sau) để điều chỉnh một hệ thống. Nhưng tôi không bao giờ cân nhắc việc không lập chỉ mục trừ khi tôi có thể chứng minh tại sao tôi lại làm như vậy.


2
Bạn lấy những con số đó từ đâu? 98% dường như cực kỳ cao, đặc biệt là trong thời đại của "dữ liệu lớn" (còn gọi là lưu trữ mọi thứ và hy vọng nó sẽ hữu ích vào một ngày nào đó)
rm

7

Bạn nên lập hồ sơ sử dụng và tải cơ sở dữ liệu của mình và xác định các tắc nghẽn do thiếu chỉ mục - hoặc do quá nhiều chỉ mục. Sau đó, bạn phải chọn chỉ mục thích hợp - và điều đó đòi hỏi kiến ​​thức tốt về các kỹ thuật lập chỉ mục cơ sở dữ liệu cụ thể.


7

Khá đơn giản là một trong những loạt bài viết hay nhất được viết về việc chọn chỉ mục nào và tại sao lại là của Gail Shaw. Bạn có thể tìm thấy các bài viết bằng cách nhấn vào đây

Câu hỏi bạn hỏi có thể được trả lời 50 cách khác nhau. Nó thực sự tập trung vào dữ liệu bạn có và cách nó sẽ được truy vấn. Một quy tắc chung là bạn phải luôn có một chỉ mục được nhóm trên mỗi bảng để tránh các đống. Các chỉ mục được nhóm nên thường càng nhỏ càng tốt. Nếu bảng có chỉ mục được nhóm thì tất cả các bản ghi chỉ mục trên các trang lá của chỉ mục không được phân cụm sẽ lưu trữ giá trị bản ghi của chỉ mục được nhóm tương ứng để tra cứu dấu trang. Nếu một bảng là một đống thì SQL sẽ tạo một mã định danh duy nhất để tra cứu dấu trang. Tôi không thể nhớ lại kích thước của nó là 8 hoặc 16 byte. Điều này có thể trở thành một kiểu dữ liệu lớn hơn nhiều sau đó nói INT. Hãy tưởng tượng có 8 chỉ mục không được nhóm trên một bảng heap.


Chỉ cần một lưu ý cho độc giả: "SQL tra cứu dấu trang" của MS SQL tương đương với "ACCESS BY ROWID" của Oracle. Xem stackoverflow.com/a/820731/122727
kubanchot

5

Tôi muốn thêm vào đây rằng các cơ sở dữ liệu khác nhau đòi hỏi các chiến lược khác nhau. Ví dụ, hãy so sánh MySQL w / InnoDB và PostgreSQL.

InnoDB

Các bảng InnoDB về cơ bản là một chỉ mục b-cây của khóa chính được mở rộng để bao gồm thông tin hàng trong mục nhập chỉ mục. Quét thứ tự vật lý không được hỗ trợ và tất cả các lần quét xảy ra theo thứ tự hợp lý. Điều này có nghĩa là hai điều:

  1. Quét liên tiếp trong Innodb tạo ra rất nhiều I / O đĩa ngẫu nhiên

  2. Chỉ số khóa chính phải được duyệt qua bất kể người ta có sử dụng chỉ mục phụ hay không.

  3. Tra cứu khóa chính nhanh hơn trong mô hình này so với bất kỳ phương pháp nào khác.

Trong trường hợp này, điều rất quan trọng là lập chỉ mục đủ các trường trong bảng nhiều trang. Quy tắc điển hình là lập chỉ mục mọi thứ bạn muốn lọc theo.

PostgreSQL

PostgreSQL sử dụng các tệp heap, một bảng cho mỗi tệp (một số bảng có thể là nhiều tệp) trong đó các bộ dữ liệu được phân bổ từ không gian trống của heap đó. Quét thứ tự vật lý được hỗ trợ. Để quét thứ tự hợp lý để làm việc, một chỉ mục phải được thêm vào.

Các khóa chính trong PostgreSQL về cơ bản là một tập hợp con của các chỉ mục duy nhất trong đó không có giá trị nào có thể là NULL. Các ràng buộc ĐỘC ĐÁO được thực hiện bằng cách sử dụng các chỉ mục ngầm định và một số loại chỉ mục khác được hỗ trợ với các hoạt động khác nhau có thể có trong chỉ mục.

Điều này có nghĩa là:

  1. Tra cứu khóa chính, giả sử một tablerequire hợp lý đánh vào tệp chỉ mục tệp bảng. Điều này chậm hơn đáng kể so với cách tiếp cận của MySQL trong đó chỉ mục phải được duyệt qua và hàng được chứa trong chỉ mục.

  2. Quét thứ tự vật lý thực hiện tốt hơn nhiều, giảm I / O đĩa ngẫu nhiên trong đó số lượng hàng đáng kể sẽ được xử lý.

  3. Quét chỉ mục phụ hoạt động tốt hơn so với MySQL vì chỉ có một chỉ mục phải được duyệt qua để đến phần vật lý của bảng.

Trong mô hình này, các chỉ mục thường là cần thiết nhưng người lập kế hoạch có nhiều tự do hơn khi sử dụng một chỉ mục và ý nghĩa của việc không sử dụng một chỉ mục thường ít nghiêm trọng hơn. Các bảng thường được tối ưu hóa nhiều hơn (thay vì chuyên về tra cứu pkey) và do đó cần ít chỉ mục hơn.

TL; DR

Biết RDBMS của bạn.



2

Ngay cả với tất cả các liên kết trên, bạn cần xem Kimberly Tripp đã viết gì về việc chăm sóc, cho ăn và sử dụng các chỉ mục.

Để bắt đầu, hãy theo liên kết này đến bộ sưu tập các bài đăng trên blog liên quan đến chỉ mục của Kimberly. Bạn có thể khám phá các chủ đề cụ thể bằng cách sử dụng các tiện ích "Trên trang này" và "Danh mục" ở bên trái cửa sổ trình duyệt của bạn.

Có rất nhiều thông tin ở đây, nhưng đừng nản chí.

Trang Giới thiệu của Kimberly ở đây


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.