Có bao nhiêu chỉ mục cơ sở dữ liệu là quá nhiều?

Tôi đang làm việc trong một dự án với cơ sở dữ liệu Oracle khá lớn (mặc dù câu hỏi của tôi cũng áp dụng tốt cho các cơ sở dữ liệu khác). Chúng tôi có một giao diện web cho phép người dùng tìm kiếm trên hầu hết mọi tổ hợp trường có thể có.

Để làm cho những tìm kiếm này diễn ra nhanh chóng, chúng tôi đang thêm chỉ mục vào các trường và kết hợp các trường mà chúng tôi tin rằng người dùng sẽ thường tìm kiếm. Tuy nhiên, vì chúng tôi không thực sự biết khách hàng của mình sẽ sử dụng phần mềm này như thế nào, nên thật khó để biết nên tạo chỉ mục nào.

Không gian không phải là một mối quan tâm; chúng tôi có một ổ RAID 4 terabyte mà chúng tôi đang sử dụng chỉ một phần nhỏ. Tuy nhiên, tôi lo lắng về các hình phạt hiệu suất có thể xảy ra khi có quá nhiều chỉ số. Bởi vì những chỉ mục đó cần được cập nhật mỗi khi một hàng được thêm, xóa hoặc sửa đổi, tôi tưởng tượng sẽ là một ý tưởng tồi nếu có hàng chục chỉ mục trên một bảng.

Vậy bao nhiêu chỉ số được coi là quá nhiều? 10? 25? 50? Hay tôi chỉ nên đề cập đến những trường hợp thực sự, thực sự phổ biến và hiển nhiên và bỏ qua mọi thứ khác?

Nó phụ thuộc vào các hoạt động xảy ra trên bảng.

Nếu có nhiều SELECT và rất ít thay đổi, hãy lập chỉ mục tất cả những gì bạn thích .... những điều này sẽ (có khả năng) tăng tốc các câu lệnh SELECT.

Nếu bảng bị ảnh hưởng nhiều bởi CẬP NHẬT, CHÈN + XÓA ... thì chúng sẽ rất chậm với rất nhiều chỉ mục vì tất cả chúng cần được sửa đổi mỗi khi một trong những hoạt động này diễn ra

Phải nói rằng, rõ ràng bạn có thể thêm rất nhiều chỉ mục vô nghĩa vào một bảng mà sẽ không làm được gì cả. Việc thêm các chỉ mục B-Tree vào một cột có 2 giá trị khác biệt sẽ là vô nghĩa vì nó không bổ sung bất cứ thứ gì về mặt tra cứu dữ liệu. Các giá trị trong cột càng độc đáo thì chỉ mục đó càng được hưởng lợi nhiều hơn.

Tôi thường tiến hành như thế này.

1. Nhận nhật ký của các truy vấn thực chạy trên dữ liệu vào một ngày bình thường.
2. Thêm chỉ mục để các truy vấn quan trọng nhất đạt được các chỉ mục trong kế hoạch thực thi của chúng.
3. Cố gắng tránh lập chỉ mục các trường có nhiều cập nhật hoặc chèn
4. Sau một vài chỉ mục, hãy lấy một nhật ký mới và lặp lại.

Như với tất cả các tối ưu hóa, tôi dừng khi đạt đến hiệu suất được yêu cầu (điều này rõ ràng ngụ ý rằng điểm 0. sẽ nhận được các yêu cầu hiệu suất cụ thể).

Mọi người khác đã cho bạn lời khuyên tuyệt vời. Tôi có thêm một gợi ý cho bạn khi bạn tiến lên. Tại một số thời điểm, bạn phải đưa ra quyết định về chiến lược lập chỉ mục tốt nhất của mình. Tuy nhiên, cuối cùng, chiến lược lập chỉ mục CÓ KẾ HOẠCH tốt nhất vẫn có thể tạo ra các chỉ mục mà cuối cùng vẫn không được sử dụng. Một chiến lược cho phép bạn tìm các chỉ mục không được sử dụng là theo dõi việc sử dụng chỉ mục. Bạn thực hiện như sau: -

alter index my_index_name monitoring usage;

Sau đó, bạn có thể theo dõi liệu chỉ mục có được sử dụng hay không từ thời điểm đó trở đi bằng cách truy vấn v $ object_usage. Thông tin về điều này có thể tìm thấy trong Hướng dẫn dành cho Quản trị viên Cơ sở dữ liệu Oracle® .

Chỉ cần nhớ rằng nếu bạn có chiến lược nhập kho là giảm các chỉ mục trước khi cập nhật bảng, sau đó tạo lại chúng, bạn sẽ phải thiết lập chỉ mục để theo dõi lại và bạn sẽ mất mọi lịch sử theo dõi cho chỉ mục đó.

Trong kho dữ liệu, việc có số lượng chỉ mục cao là rất phổ biến. Tôi đã làm việc với các bảng dữ kiện có hai trăm cột và 190 trong số đó được lập chỉ mục.

Mặc dù có một chi phí cho điều này, nó phải được hiểu trong bối cảnh rằng trong kho dữ liệu, chúng tôi thường chỉ chèn một hàng một lần, chúng tôi không bao giờ cập nhật nó, nhưng sau đó nó có thể tham gia vào hàng nghìn truy vấn SELECT có thể được lợi từ việc lập chỉ mục trên bất kỳ Các cột.

Để có tính linh hoạt tối đa, kho dữ liệu thường sử dụng các chỉ mục bitmap cột đơn ngoại trừ các cột có số lượng cao, trong đó các chỉ mục btree (được nén) có thể được sử dụng.

Chi phí duy trì chỉ mục chủ yếu liên quan đến chi phí ghi vào rất nhiều khối và khối sẽ tách ra khi các hàng mới được thêm vào với các giá trị "ở giữa" các phạm vi giá trị hiện có cho cột đó. Điều này có thể được giảm thiểu bằng cách phân vùng và tải dữ liệu mới được căn chỉnh với sơ đồ phân vùng và bằng cách sử dụng chèn đường dẫn trực tiếp.

Để giải quyết câu hỏi của bạn một cách trực tiếp hơn, tôi nghĩ rằng có thể tốt để lập chỉ mục lúc đầu, nhưng đừng ngại thêm nhiều chỉ mục hơn nếu các truy vấn chống lại bảng có lợi.

Trong một cách diễn giải của Einstein về sự đơn giản, hãy thêm nhiều chỉ mục tùy thích và không thêm nữa.

Tuy nhiên, nghiêm túc mà nói, mọi chỉ mục bạn thêm đều yêu cầu bảo trì bất cứ khi nào dữ liệu được thêm vào bảng. Trên các bảng chủ yếu chỉ được đọc, nhiều chỉ mục là một điều tốt. Trên các bảng có tính năng động cao, càng ít càng tốt.

Lời khuyên của tôi là bao gồm các trường hợp phổ biến và hiển nhiên, sau đó, khi bạn gặp phải các vấn đề mà bạn cần tốc độ cao hơn trong việc lấy dữ liệu từ các bảng cụ thể, hãy đánh giá và thêm các chỉ số vào thời điểm đó.

Ngoài ra, bạn nên đánh giá lại kế hoạch lập chỉ mục của mình vài tháng một lần, chỉ để xem liệu có bất kỳ chỉ số mới nào cần lập chỉ mục hoặc bất kỳ chỉ số nào bạn đã tạo không được sử dụng cho bất kỳ thứ gì và cần được loại bỏ .

Ngoài những điểm mà mọi người khác đã nêu ra, Trình tối ưu hóa dựa trên chi phí phải chịu chi phí khi tạo kế hoạch cho một câu lệnh SQL nếu có nhiều chỉ mục hơn vì có nhiều kết hợp hơn để nó xem xét. Bạn có thể giảm điều này bằng cách sử dụng chính xác các biến liên kết để các câu lệnh SQL ở trong bộ đệm SQL. Oracle sau đó có thể thực hiện phân tích cú pháp mềm và sử dụng lại kế hoạch mà nó đã tìm thấy lần trước.

Như mọi khi, không có gì là đơn giản. Nếu có các cột và biểu đồ bị lệch liên quan thì đây có thể là một ý tưởng tồi.

Trong các ứng dụng web của mình, chúng tôi có xu hướng giới hạn các kết hợp tìm kiếm mà chúng tôi cho phép. Nếu không, bạn sẽ phải kiểm tra mọi sự kết hợp theo nghĩa đen để đảm bảo rằng bạn không gặp phải vấn đề tiềm ẩn mà một ngày nào đó ai đó sẽ tìm ra. Chúng tôi cũng đã triển khai giới hạn tài nguyên để ngăn chặn điều này gây ra sự cố ở những nơi khác trong ứng dụng nếu xảy ra sự cố.

Tôi đã thực hiện một số thử nghiệm đơn giản trên dự án thực và cơ sở dữ liệu MySql thực của mình. Tôi đã trả lời trong chủ đề này: Chi phí lập chỉ mục nhiều cột db là bao nhiêu?

Nhưng tôi nghĩ sẽ tốt hơn nếu tôi trích dẫn nó ở đây:

Tôi đã thực hiện một số thử nghiệm đơn giản bằng cách sử dụng dự án thực của mình và cơ sở dữ liệu MySql thực.

Kết quả của tôi là: thêm chỉ mục trung bình (1-3 cột trong một chỉ mục) vào bảng - làm cho việc chèn chậm hơn 2,1%. Vì vậy, nếu bạn thêm 20 chỉ mục, lượt chèn của bạn sẽ chậm hơn 40-50%. Nhưng lựa chọn của bạn sẽ nhanh hơn 10-100 lần.

Vì vậy, nó là ok để thêm nhiều chỉ mục? - Tùy :) Tôi đã cho bạn kết quả của tôi - Bạn quyết định!

Cuối cùng bạn cần bao nhiêu chỉ mục phụ thuộc vào hoạt động của các ứng dụng chạy trên máy chủ cơ sở dữ liệu của bạn.

Nói chung, bạn càng chèn nhiều thì chỉ mục của bạn càng trở nên khó khăn hơn. Mỗi lần bạn thực hiện chèn, tất cả các chỉ mục bao gồm bảng đó phải được cập nhật.

Bây giờ nếu ứng dụng của bạn có một lượng đọc tốt hoặc thậm chí nhiều hơn nếu gần như là đọc tất cả, thì các chỉ mục là cách để thực hiện vì sẽ có những cải tiến hiệu suất lớn với chi phí rất thấp.

Không có câu trả lời tĩnh theo ý kiến ​​của tôi, loại điều này thuộc 'điều chỉnh hiệu suất'.

Có thể là mọi thứ mà ứng dụng của bạn thực hiện đều được tra cứu bằng khóa chính hoặc có thể là tùy chọn trong đó các truy vấn được thực hiện qua các tổ hợp trường không bị giới hạn và bất kỳ trường nào cụ thể đều có thể được sử dụng tại bất kỳ thời điểm nào.

Ngoài việc chỉ lập chỉ mục, còn có việc đăng ký lại DB của bạn để bao gồm các trường tìm kiếm được tính toán, bảng phân tách, v.v. - nó thực sự phụ thuộc vào hình dạng tải và thông số truy vấn của bạn, bao nhiêu / dữ liệu 'thực sự' cần được kết xuất lại bởi một truy vấn.

Nếu toàn bộ DB của bạn được bao phủ bởi các mặt tiền thủ tục được lưu trữ, thì việc biến trở nên dễ dàng hơn một chút, vì bạn không phải lo lắng về mọi truy vấn đặc biệt. Hoặc bạn có thể hiểu sâu về các loại truy vấn sẽ đánh vào DB của bạn và có thể giới hạn việc điều chỉnh đối với những truy vấn đó.

Đối với SQL Server, tôi thấy công cụ cố vấn Điều chỉnh Cơ sở dữ liệu hữu ích - bạn thiết lập khối lượng công việc 'điển hình' và nó có thể đưa ra các đề xuất về việc thêm / xóa chỉ mục và thống kê. Tôi chắc chắn rằng các DB khác có các công cụ tương tự, dù là 'chính thức' hoặc bên thứ ba.

Đây thực sự là một câu hỏi lý thuyết nhiều hơn thực tế. Chỉ số ảnh hưởng đến hiệu suất của bạn phụ thuộc vào phần cứng bạn có, phiên bản Oracle, các loại chỉ mục, v.v. Hôm qua, tôi đã nghe Oracle công bố một bộ lưu trữ chuyên dụng do HP sản xuất, được cho là hoạt động nhanh hơn 10 lần với cơ sở dữ liệu 11g. Đối với trường hợp của bạn, có thể có một số giải pháp: 1. Có một lượng lớn chỉ mục (> 20) và xây dựng lại chúng hàng ngày (hàng đêm). Điều này sẽ đặc biệt hữu ích nếu bảng nhận được hàng nghìn cập nhật / xóa hàng ngày. 2. Phân vùng bảng của bạn (nếu điều đó áp dụng mô hình dữ liệu của bạn). 3. Sử dụng một bảng riêng biệt cho dữ liệu mới / cập nhật và chạy quy trình hàng đêm kết hợp dữ liệu với nhau. Điều này sẽ yêu cầu một sự thay đổi trong logic ứng dụng của bạn. 4. Chuyển sang IOT (bảng tổ chức chỉ mục), nếu dữ liệu của bạn hỗ trợ điều này.

Tất nhiên có thể có nhiều giải pháp khác cho trường hợp như vậy. Đề xuất đầu tiên của tôi dành cho bạn, là sao chép DB sang môi trường phát triển và chạy một số thử nghiệm căng thẳng đối với nó.

Nếu bạn chủ yếu đọc (và ít cập nhật) thì thực sự không có lý do gì để không lập chỉ mục mọi thứ bạn cần lập chỉ mục. Nếu bạn cập nhật thường xuyên, thì bạn có thể cần phải thận trọng về số lượng chỉ mục của bạn. Không có con số khó, nhưng bạn sẽ nhận thấy khi mọi thứ bắt đầu chậm lại. Đảm bảo rằng chỉ mục được phân nhóm của bạn là chỉ mục có ý nghĩa nhất dựa trên dữ liệu.

Một điều bạn có thể xem xét là xây dựng các chỉ mục để nhắm mục tiêu một tổ hợp tìm kiếm tiêu chuẩn. Nếu cột1 thường được tìm kiếm và cột2 thường được sử dụng với nó và cột3 đôi khi được sử dụng với cột2 và cột1, thì chỉ mục trên cột1, cột2 và cột3 theo thứ tự đó có thể được sử dụng cho bất kỳ trường hợp nào trong ba trường hợp đó, mặc dù chỉ một chỉ số phải được duy trì.

Chỉ mục áp dụng chi phí khi bảng cơ sở được cập nhật. Một chỉ mục cung cấp một lợi ích khi nó được sử dụng để sắp xếp một truy vấn. Đối với mỗi chỉ số, bạn cần cân đối giữa chi phí và lợi ích. Truy vấn chạy chậm hơn bao nhiêu nếu không có chỉ mục? Lợi ích của việc chạy nhanh hơn là bao nhiêu? Bạn hoặc người dùng của bạn có thể chịu được tốc độ chậm khi thiếu chỉ mục không?

Bạn có thể chịu đựng thêm thời gian cần thiết để hoàn thành cập nhật không?

Bạn cần so sánh chi phí và lợi ích. Đó là đặc biệt cho tình huống của bạn. Không có số lượng chỉ mục kỳ diệu nào vượt qua ngưỡng "quá nhiều".

Ngoài ra còn có chi phí của không gian cần thiết để lưu chỉ mục, nhưng bạn đã nói rằng trong tình huống của bạn đó không phải là vấn đề. Điều này cũng đúng trong hầu hết các trường hợp, với điều kiện dung lượng ổ đĩa rẻ như thế nào.

Có bao nhiêu cột? Tôi luôn được yêu cầu tạo chỉ mục một cột, không phải nhiều cột. Vì vậy, không có nhiều chỉ mục hơn số lượng cột, IMHO.

Điều thực sự xảy ra là đừng thêm chỉ mục trừ khi bạn biết (và điều này thường có nghĩa là thu thập số liệu thống kê sử dụng) rằng nó sẽ được sử dụng thường xuyên hơn nhiều so với khi được cập nhật.

Bất kỳ chỉ mục nào không đáp ứng tiêu chí đó sẽ khiến bạn tốn nhiều chi phí để xây dựng lại hơn là hình phạt về hiệu suất của việc không có nó trong trường hợp kỳ lạ mà nó đã được sử dụng.

Máy chủ Sql cung cấp cho bạn một số công cụ tốt cho phép bạn xem chỉ mục nào đang thực sự được sử dụng. Bài viết này, http://www.mssqltips.com/tip.asp?tip=1239 , cung cấp cho bạn một số truy vấn để bạn có cái nhìn sâu sắc hơn về mức độ sử dụng của một chỉ mục, thay vì mức độ cập nhật của chỉ mục.

Nó hoàn toàn dựa trên các cột đang được sử dụng trong mệnh đề Where. Và với tư cách là Quy tắc Ngón tay cái, chúng ta phải có các chỉ mục trên các Cột Khoá Ngoại để tránh bị CHẾT. Báo cáo AWR nên phân tích định kỳ để hiểu nhu cầu của các chỉ mục.