Câu hỏi của tôi liên quan đến việc sử dụng các chỉ mục.
Tôi nên bắt đầu lập chỉ mục ngay từ đầu hoặc khi vấn đề về hiệu suất phát sinh?
Chúng tôi cũng có thể tạo chỉ mục tạm thời trong khi thực hiện một truy vấn. Những ưu và nhược điểm của các kỹ thuật như vậy là gì?
Câu trả lời:
Tôi nên bắt đầu lập chỉ mục ngay từ đầu hoặc khi vấn đề về hiệu suất phát sinh?
Chiến lược lập chỉ mục có xu hướng phát triển khi các mô hình sử dụng xuất hiện. Điều đó nói rằng, cũng có các chiến lược và hướng dẫn thiết kế có thể được áp dụng lên phía trước.
Chọn một khóa cụm tốt . Bạn thường có thể xác định chỉ mục được nhóm thích hợp tại thời điểm thiết kế, dựa trên mẫu chèn dự kiến vào bảng. Nếu một trường hợp hấp dẫn nổi lên cho một sự thay đổi trong tương lai, vì vậy hãy là nó.
Tạo các ràng buộc chính và duy nhất khác của bạn . Chúng sẽ được thực thi bởi các chỉ mục duy nhất.
Tạo khóa ngoại của bạn và các chỉ mục không được liên kết . Khóa ngoại là các cột tham gia được tham chiếu thường xuyên nhất của bạn, vì vậy hãy lập chỉ mục chúng từ đầu.
Tạo các chỉ mục cho bất kỳ truy vấn rõ ràng có tính chọn lọc cao . Đối với các mẫu truy vấn bạn đã biết sẽ có tính chọn lọc cao và có khả năng sử dụng tra cứu thay vì quét.
Ngoài những điều trên, hãy thực hiện một cách tiếp cận dần dần và toàn diện để thực hiện các chỉ mục mới. Theo tổng thể, tôi có nghĩa là đánh giá lợi ích và tác động tiềm năng đối với tất cả các truy vấn và chỉ mục hiện có khi đánh giá một bổ sung.
Một vấn đề không phổ biến trong các vòng tròn SQL Server là quá mức, do kết quả của hướng dẫn từ các gợi ý DMV và chỉ số SSMS bị thiếu. Cả hai công cụ này đều không đánh giá các chỉ mục hiện có và sẽ vui lòng đề nghị bạn tạo một chỉ mục 6 cột mới thay vì thêm một cột vào chỉ mục 5 cột hiện có.
-- If you have this
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
)
-- But your query would benefit from the addition of a column
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
, [col6] ASC
)
-- SSMS will suggest you create this instead
CREATE NONCLUSTERED INDEX [IX_MyTable_AnotherIndexWithTheSameColumnsAsTheExistingIndexPlusCol6] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
, [col6] ASC
)Kimberly Tripp có một số tài liệu tuyệt vời về chiến lược lập chỉ mục mà trong khi SQL tập trung có thể áp dụng cho các nền tảng khác. Đối với dân gian SQL Server, có một số công cụ tiện dụng để xác định các bản sao giống như ví dụ trên.
Chúng tôi cũng có thể tạo chỉ mục tạm thời trong khi thực hiện một truy vấn. Những ưu và nhược điểm của các kỹ thuật như vậy là gì?
Điều này thường chỉ áp dụng cho các truy vấn hiếm khi chạy, điển hình là ETL. Bạn cần đánh giá:
Có những rủi ro thực sự liên quan đến cả hai phương pháp:
Tùy chọn a) Lập chỉ mục từ đầu, nhưng không nhận ra bạn đã tạo một số chỉ mục không bao giờ được sử dụng. Chúng thêm một số chi phí (đáng chú ý nhất vào các truy vấn sửa đổi dữ liệu, nhưng cũng tối ưu hóa các câu lệnh CHỌN cố gắng xác định chỉ mục tốt nhất).
Bạn sẽ cần phải kỷ luật bản thân để xác định các chỉ mục không còn được sử dụng nữa và thử và loại bỏ chúng (PostgreQuery có thể làm điều này; thật không may, MySQL bằng cách so sánh là rất yếu trong trường hợp này.)
Tùy chọn b) Không thêm chỉ mục cho đến khi mọi người bắt đầu phàn nàn hoặc công cụ chẩn đoán của bạn kích hoạt một số truy vấn nhất định chậm và có thể được cải thiện.
Rủi ro mà bạn giới thiệu là bạn không có cửa sổ thời gian đủ lớn giữa khi bạn nhận thấy bạn cần chỉ mục và khi bạn phải thêm nó.
PostgreSQL hỗ trợ xây dựng các chỉ mục CONCURRENTLY, giúp giảm một số căng thẳng từ yêu cầu bổ sung chỉ mục đột ngột này, nhưng có một số lưu ý trong hướng dẫn.
Tùy chọn (b) có xu hướng là sở thích của tôi, nhưng tôi nghĩ rằng sự kết hợp của cả hai tùy chọn có lẽ là giải pháp tốt nhất. Nó liên quan đến mức độ tự tin của bạn về việc bạn có nghĩ rằng một chỉ số sẽ thực sự được sử dụng hay không.
Điều làm cho điều này trở thành một cuộc thảo luận đặc biệt phức tạp là thường dễ thay đổi các chỉ mục, nhưng khó thay đổi lược đồ hơn. Tôi không muốn thúc đẩy phản ứng chậm trễ của b như một cái cớ để liều lĩnh.
Ngoài câu trả lời của Mark
Bạn có thể cảm nhận bằng cách có dữ liệu thử nghiệm thực tế với số lượng dự kiến. Tôi đã thấy nhiều, rất nhiều (quá nhiều) trường hợp một truy vấn chạy OK với 1000 hàng nhưng không phải là hàng triệu sản phẩm.
Nếu bạn có thể, hãy làm việc trên một bản sao của sản xuất sau này,
Tất nhiên, tôi đã thấy vấn đề kỳ lạ chỉ trong sản xuất vì mô hình sử dụng khi mọi thứ khác giống hệt nhau
Chỉ số tạm thời? Ngoài các mẫu tải ETL, nếu bạn cần chúng một lần, bạn sẽ cần lại chúng. Đừng quên: tạo / thả chỉ mục là ghi và được ghi = tải thêm
Chỉ cần thêm một vài điều.
Đây là cách tiếp cận của tôi.
Đừng ngại đặt > 0hoặc > ""trong các mệnh đề của bạn cho các cột không được sử dụng.
select * from blah
where A="one"
and B="two"
and C>="" --to match index
and D="four"
--This will use your existing index. No need to create a redundant one.Tôi sẽ cố gắng chỉ trả lời câu hỏi đầu tiên. Nếu bạn có thể ước tính thậm chí ngay từ đầu có bao nhiêu bản ghi bạn sẽ có trong các bảng của mình sau một khoảng thời gian nhất định, thì tôi sẽ nói rằng tốt hơn là bắt đầu từ đầu để thiết kế một số chỉ mục. Hãy thử sử dụng một số công cụ kiểm tra hoặc tập lệnh kiểm tra sẽ tự động hóa càng nhiều cuộc gọi càng tốt cho các cuộc gọi ứng dụng mà bạn nghĩ sẽ được sử dụng thường xuyên nhất và bạn sẽ thấy những gì có thể tránh được việc quét bảng ngay từ đầu.
Nó sẽ là một công việc đoán ngay từ đầu, nhưng theo thời gian, khi bạn có số liệu thống kê sử dụng phù hợp, bạn sẽ có một hình ảnh rõ ràng hơn.