Khi nào tôi nên xây dựng lại các chỉ mục?

Khi nào tôi nên xây dựng lại các chỉ mục trong cơ sở dữ liệu quan hệ của mình (SQL Server)?

Có một trường hợp để xây dựng lại các chỉ số một cách thường xuyên?

Có nguy cơ trở nên quá chung chung trong câu trả lời của tôi, tôi sẽ nói rằng bạn nên chạy một quy trình bảo trì chỉ mục thường xuyên. Tuy nhiên, quy trình bảo trì chỉ mục của bạn chỉ nên xây dựng lại / sắp xếp lại các chỉ mục yêu cầu cụ thể.

Điều này đặt ra câu hỏi: khi nào một chỉ số yêu cầu được xây dựng lại hoặc tổ chức lại? Rolando đã chạm vào điều này độc đáo. Một lần nữa, tôi có nguy cơ cực kỳ rộng. Một chỉ số yêu cầu bảo trì khi mức độ phân mảnh ảnh hưởng xấu đến hiệu suất. Mức độ phân mảnh này có thể thay đổi dựa trên kích thước và thành phần của chỉ số.

Nói về SQL Server, tôi có xu hướng chọn kích thước chỉ mục và mức phân mảnh chỉ mục tại điểm tôi bắt đầu thực hiện bảo trì chỉ mục. Nếu một chỉ mục chứa ít hơn 100 trang, tôi sẽ thực hiện không bảo trì.

Nếu một chỉ số nằm trong khoảng từ 10% đến 30%, tôi sẽ REORGANIZElập chỉ mục và UPDATEthống kê. Nếu một chỉ mục bị phân mảnh trên 30%, tôi sẽ REBUILDlập chỉ mục - không UPDATE STATISTICS, vì điều này được chăm sóc bởi REBUILD. Hãy nhớ rằng việc xây dựng lại chỉ cập nhật đối tượng thống kê được liên kết trực tiếp với chỉ mục. Thống kê cột khác sẽ cần phải được duy trì riêng.

Câu trả lời này thực sự chỉ là một cách dài để nói: Có, bạn nên thực hiện bảo trì chỉ mục thường xuyên, nhưng chỉ trên các chỉ mục cần nó.

Khi nào tôi nên xây dựng lại các chỉ mục trong cơ sở dữ liệu quan hệ của mình (ví dụ: SQL Server)?

Bạn nên xây dựng lại các chỉ mục khi chúng trở nên phân mảnh cao bởi các sự kiện đặc biệt. Ví dụ: bạn thực hiện tải dữ liệu lớn, số lượng lớn vào một bảng được lập chỉ mục.

Có một trường hợp để xây dựng lại các chỉ số một cách thường xuyên?

Vậy điều gì sẽ xảy ra nếu các chỉ mục của bạn trở nên rời rạc một cách thường xuyên do hoạt động thường xuyên? Bạn có nên lên lịch xây dựng lại thường xuyên? Họ nên chạy thường xuyên như thế nào?

Tom Kyte , trong chủ đề Ask Tom cổ điển này , khuyến nghị:

Độ trễ thời gian giữa các lần xây dựng lại chỉ số sẽ xấp xỉ TUYỆT VỜI.

...

Không biết làm thế nào để nói điều đó tốt hơn - chỉ số muốn trở nên to và mập hơn khi có thêm không gian. Đó là trên một cột bạn cập nhật - di chuyển mục nhập chỉ mục từ nơi này sang nơi khác trong chỉ mục. Một ngày, hàng có mã "A", ngày hôm sau mã là "G", sau đó "Z" rồi "H", v.v. Vì vậy, mục chỉ mục cho hàng di chuyển từ nơi này sang nơi khác trong chỉ mục. Vì vậy, nó cần không gian - sẽ, nếu không có không gian, chúng tôi chia khối thành hai - và tạo không gian. Bây giờ chỉ số đang béo lên. Theo thời gian, chỉ số có kích thước gấp 2-3 lần so với khi bạn bắt đầu và "trống một nửa hoặc nhiều hơn" Nhưng điều đó vẫn ổn vì bạn di chuyển các hàng xung quanh. Bây giờ khi chúng tôi di chuyển các hàng xung quanh, chúng tôi không còn phải phân chia các khối để tạo phòng - phòng đã có sẵn.

Sau đó, bạn đi cùng và xây dựng lại hoặc thả và tạo lại chỉ mục (có cùng tác dụng - chỉ là việc xây dựng lại là "an toàn hơn" - không có cơ hội mất chỉ mục và có thể nhanh hơn vì chỉ mục có thể được xây dựng lại bằng cách quét chỉ mục hiện có thay vì quét bảng và sắp xếp và xây dựng một chỉ mục mới). Bây giờ, tất cả không gian tốt đẹp đó đã biến mất. Chúng tôi bắt đầu quá trình chia tách các khối một lần nữa - đưa chúng tôi trở lại nơi chúng tôi bắt đầu.

Bạn đã tiết kiệm không gian.

Các chỉ số là trở lại đúng như vậy.

Bạn sẽ lãng phí thời gian để xây dựng lại một lần nữa khiến cho vòng luẩn quẩn này lặp lại.

Logic ở đây là âm thanh, nhưng nó thiên vị so với cấu hình tải nặng đọc.

Một chỉ số "béo" (nghĩa là một chỉ số có nhiều khoảng trống) thực sự giữ một khoảng trống tốt cho các hàng mới và di chuyển, do đó giảm phân chia trang và giữ cho tốc độ ghi của bạn nhanh hơn. Tuy nhiên, khi bạn đọc từ chỉ số chất béo đó, bạn sẽ phải đọc nhiều trang hơn để có cùng dữ liệu vì giờ đây bạn đang lọc qua nhiều không gian trống hơn. Điều này làm chậm việc đọc của bạn xuống.

Vì vậy, trong các cơ sở dữ liệu nặng, bạn muốn thường xuyên xây dựng lại hoặc sắp xếp lại các chỉ mục của mình. (Matt M đã có câu trả lời cụ thể cho câu hỏi này trong bao lâu và trong điều kiện nào? ) thường xuyên.

Hầu hết mọi người xây dựng lại chúng một cách thường xuyên để chúng không bao giờ bị phân mảnh. Khi bạn cần xây dựng lại chúng dựa trên việc chúng bị phân mảnh nhanh như thế nào. Một số chỉ mục sẽ cần phải được xây dựng lại thường xuyên, những người khác về cơ bản là không bao giờ. Kiểm tra tập lệnh mà SQLFool kết hợp với nhau để xử lý rất nhiều công cụ tìm ra thứ này cho bạn.

Như đã lưu ý trong câu trả lời được chấp nhận từ Matt M, một quy tắc chung là các chỉ số bị phân mảnh trên 30% nên được xây dựng lại.

Truy vấn này sẽ giúp bạn tìm thấy có bao nhiêu chỉ mục bạn bị phân mảnh trên 30% (khi bạn có một số chỉ mục, bạn nên xây dựng lại chúng):

SELECT DB_NAME() AS DBName,
       OBJECT_NAME(ind.object_id) AS TableName,
       ind.name AS IndexName,
       indexstats.index_type_desc AS IndexType,
       indexstats.avg_fragmentation_in_percent,
       indexstats.fragment_count,
       indexstats.avg_fragment_size_in_pages,
       SUM(p.rows) AS Rows 
  FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
         INNER JOIN sys.indexes AS ind ON (    ind.object_id = indexstats.object_id
                                           AND ind.index_id = indexstats.index_id)
         INNER JOIN sys.partitions AS p ON (    ind.object_id = p.object_id
                                            AND ind.index_id = p.index_id)
 WHERE indexstats.avg_fragmentation_in_percent > 30
 GROUP BY
       OBJECT_NAME(ind.object_id),
       ind.name,
       indexstats.index_type_desc,
       indexstats.avg_fragmentation_in_percent,
       indexstats.fragment_count,
       indexstats.avg_fragment_size_in_pages 
 ORDER BY indexstats.avg_fragmentation_in_percent DESC

Khi nào tôi nên xây dựng lại các chỉ mục?

Khi tỷ lệ phân mảnh chỉ số là hơn 30%.

Có một trường hợp để xây dựng lại các chỉ số một cách thường xuyên?

Không có trường hợp nào như vậy, nhưng nói chung, thực hiện Chỉ số bảo trì một lần trong một tuần, vào cuối tuần là cách tốt nhất để giữ môi trường ổn định.

Tôi sẽ khuyên bạn nên sử dụng các tập lệnh bảo trì từ Ola Hallengren (tập lệnh bảo trì tốt nhất), tùy chỉnh các tập lệnh dựa trên môi trường của bạn và lên lịch để chạy vào cuối tuần.

https://ola.hallengren.com/

Lưu ý: Xin đừng quên cập nhật số liệu thống kê sau khi xây dựng lại chỉ mục, vì việc xây dựng lại chỉ mục không cập nhật tất cả các số liệu thống kê.

Như với hầu hết mọi thứ trong CNTT, nó phụ thuộc. Vấn đề gì bạn đang cố gắng khắc phục bằng cách xây dựng lại các chỉ mục? Bạn có thể chỉ ra rằng nó thực sự khắc phục vấn đề? Nếu vậy, sau đó điều chỉnh các số cho đến khi bạn tìm thấy số lượng bảo trì ít nhất bạn cần làm để khắc phục sự cố.

Nếu nó không khắc phục được sự cố, hoặc lý do bạn đang làm điều đó chỉ là để xoa dịu một số liệu mà bạn theo dõi bởi vì nó có thể làm mọi thứ tốt hơn, thì tất cả những gì bạn đang làm là đốt cháy CPU và IO và có thể làm cho vấn đề của bạn trở nên tồi tệ hơn.

Có một lập luận rằng việc sửa lỗi phân mảnh sẽ không tạo ra bất kỳ sự khác biệt nào đối với máy chủ của bạn, vậy nó có đáng để thực hiện thường xuyên không?

https://www.brentozar.com/archive/2017/12/index-maintenance-madness/

http://brentozar.com/go/defrag