Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Giảm thiểu phân mảnh chỉ mục


Đây cũng không phải là phân mảnh tốt

Tháng trước, tôi đã viết về phân mảnh chỉ mục theo cụm không mong muốn, vì vậy, lần này, tôi muốn thảo luận một số điều bạn có thể làm để tránh xảy ra phân mảnh chỉ mục. Tôi giả sử bạn đã đọc bài viết trước và quen thuộc với các thuật ngữ tôi đã định nghĩa ở đó, và trong suốt phần còn lại của bài viết này, khi tôi nói 'phân mảnh', tôi đang đề cập đến cả vấn đề phân mảnh hợp lý và mật độ trang thấp.

Chọn một khóa cụm tốt

Cấu trúc dữ liệu đắt tiền nhất cần sử dụng để loại bỏ sự phân mảnh là chỉ mục nhóm của bảng, vì nó là cấu trúc lớn nhất vì nó chứa tất cả dữ liệu bảng. Từ góc độ phân mảnh, việc chọn một khóa cụm phù hợp với mẫu chèn bảng là rất hợp lý, do đó, không có khả năng xảy ra hiện tượng chèn trên một trang không có khoảng trống và do đó gây ra chia tách trang và dẫn đến phân mảnh.

Điều gì tạo nên khóa cụm tốt nhất cho bất kỳ bảng nhất định nào là một vấn đề còn nhiều tranh luận, nhưng nói chung, bạn sẽ không hiểu sai nếu khóa cụm của bạn có các thuộc tính đơn giản sau:

  • Thu hẹp (tức là càng ít cột càng tốt)
  • Tĩnh (tức là bạn không bao giờ cập nhật nó)
  • Độc đáo
  • Không ngừng tăng lên

Đó là thuộc tính ngày càng gia tăng, là đặc tính quan trọng nhất để ngăn chặn phân mảnh, vì nó tránh việc chèn ngẫu nhiên có thể gây chia tách trang trên các trang đã đầy. Ví dụ về lựa chọn chính như vậy là các cột nhận dạng int và bigint hoặc thậm chí là một GUID tuần tự từ hàm NEWSEQUENTIALID ().

Với các loại khóa này, các hàng mới sẽ có giá trị khóa được đảm bảo cao hơn tất cả các hàng khác trong bảng và do đó, điểm chèn của hàng mới sẽ nằm ở cuối trang ngoài cùng bên phải trong cấu trúc chỉ mục được phân nhóm. Cuối cùng, các hàng mới sẽ lấp đầy trang đó và một trang khác sẽ được thêm vào phía bên phải của chỉ mục, nhưng không xảy ra hiện tượng tách trang gây hại.

Bây giờ, nếu bạn có một khóa chỉ mục nhóm không bao giờ tăng, có thể là một thủ tục rất phức tạp và khó hiểu để thay đổi nó thành một khóa ngày càng tăng, vì vậy đừng lo lắng - thay vào đó bạn có thể sử dụng hệ số lấp đầy như tôi đã thảo luận bên dưới.

Nhân tiện, để có cái nhìn sâu sắc hơn về việc chọn khóa cụm và tất cả các phân nhánh của nó, hãy xem danh mục blog Khóa cụm của Kimberly (đọc từ dưới lên).

Không cập nhật các cột chính của chỉ mục

Bất cứ khi nào một cột chính được cập nhật, nó không chỉ là một bản cập nhật tại chỗ đơn giản, mặc dù nhiều nơi trên mạng và trên sách báo rằng đó là (họ sai). Không thể cập nhật cột khóa tại chỗ vì giá trị khóa mới khi đó sẽ có nghĩa là hàng có thứ tự khóa không chính xác cho chỉ mục. Thay vào đó, cập nhật cột chính được chuyển thành xóa toàn bộ hàng cộng với chèn toàn bộ hàng với giá trị khóa mới. Nếu trang sẽ chèn hàng mới không có đủ dung lượng trên đó, thì hiện tượng tách trang sẽ xảy ra, gây ra phân mảnh.

Việc tránh cập nhật cột chính có thể dễ dàng thực hiện đối với chỉ mục được phân cụm, vì đây là một thiết kế kém yêu cầu cập nhật khóa cụm của một hàng trong bảng. Tuy nhiên, đối với các chỉ mục không hợp nhất, sẽ không thể tránh khỏi nếu các cập nhật cho bảng xảy ra liên quan đến các cột có chỉ mục không hợp nhất. Đối với những trường hợp đó, bạn sẽ cần sử dụng hệ số lấp đầy.

Không cập nhật các cột có độ dài biến đổi

Điều này nói thì dễ hơn làm. Nếu bạn phải sử dụng các cột có độ dài thay đổi và có thể chúng được cập nhật, thì có thể chúng sẽ phát triển và do đó yêu cầu nhiều không gian hơn cho hàng được cập nhật, dẫn đến việc tách trang nếu trang đã đầy.

Có một số điều bạn có thể làm để tránh phân mảnh trong trường hợp này:

  • Sử dụng hệ số lấp đầy
  • Thay vào đó, hãy sử dụng cột có độ dài cố định, nếu tổng chi phí của tất cả các byte đệm thừa ít gây ra vấn đề hơn là phân mảnh hoặc sử dụng hệ số lấp đầy
  • Sử dụng giá trị trình giữ chỗ để 'giữ chỗ' cho cột - đây là một mẹo bạn có thể sử dụng nếu ứng dụng nhập một hàng mới và sau đó quay lại để điền vào một số chi tiết, gây ra sự mở rộng cột có độ dài thay đổi
  • Thực hiện xóa cộng với chèn thay vì cập nhật

Sử dụng Hệ số lấp đầy

Như bạn có thể thấy, nhiều cách để tránh phân mảnh là không tốt vì chúng liên quan đến các thay đổi về ứng dụng hoặc lược đồ và do đó, sử dụng hệ số lấp đầy là một cách dễ dàng để giảm thiểu phân mảnh.

Yếu tố lấp đầy chỉ mục là một cài đặt cho chỉ mục chỉ định lượng không gian trống còn lại trên mỗi trang cấp độ lá khi chỉ mục được tạo, xây dựng lại hoặc tổ chức lại. Ý tưởng là có đủ không gian trống trên trang để cho phép chèn ngẫu nhiên hoặc tăng hàng (từ thẻ lập phiên bản được thêm vào hoặc cập nhật các cột có độ dài thay đổi) mà không cần trang bị lấp đầy và yêu cầu tách trang. Tuy nhiên, cuối cùng trang sẽ lấp đầy và do đó, định kỳ không gian trống cần được làm mới bằng cách xây dựng lại hoặc tổ chức lại chỉ mục (thường được gọi là thực hiện bảo trì chỉ mục). Bí quyết là tìm ra hệ số lấp đầy phù hợp để sử dụng, cùng với việc duy trì chỉ mục theo đúng định kỳ.

Bạn có thể đọc thêm về cách đặt hệ số lấp đầy trong MSDN tại đây. Đừng rơi vào bẫy của việc đặt hệ số lấp đầy cho toàn bộ phiên bản (sử dụng sp_configure) vì điều đó có nghĩa là tất cả các chỉ mục sẽ được xây dựng lại hoặc tổ chức lại bằng cách sử dụng giá trị hệ số lấp đầy đó, ngay cả những chỉ mục không có bất kỳ vấn đề phân mảnh nào. Bạn không muốn các chỉ mục nhóm lớn của mình, với các khóa đẹp ngày càng tăng, tất cả đều có 30% không gian cấp lá của chúng bị lãng phí để chuẩn bị cho các lần chèn ngẫu nhiên sẽ không bao giờ xảy ra. Tốt hơn nhiều là tìm ra chỉ mục nào thực sự bị ảnh hưởng bởi sự phân mảnh và chỉ đặt hệ số lấp đầy cho những chỉ mục đó.

Không có câu trả lời đúng hoặc công thức kỳ diệu mà tôi có thể cung cấp cho bạn cho điều này. Phương pháp thường được chấp nhận là đặt hệ số lấp đầy 70 (nghĩa là để lại 30% không gian trống) cho những chỉ mục có vấn đề về phân mảnh, theo dõi tốc độ phân mảnh xảy ra và sau đó sửa đổi hệ số lấp đầy hoặc tần suất duy trì chỉ mục (hoặc cả hai).

Đúng, điều này có nghĩa là bạn đang cố tình lãng phí không gian trong các chỉ mục để tránh phân mảnh, nhưng đó là một sự cân bằng tốt để thực hiện việc phân chia trang đắt đỏ như thế nào và việc phân mảnh có thể gây hại cho hiệu suất như thế nào. Và vâng, bất chấp những gì một số người có thể nói, điều này vẫn quan trọng ngay cả khi bạn đang sử dụng SSD.

Tóm tắt

Có một số điều đơn giản bạn có thể làm để tránh xảy ra hiện tượng phân mảnh, nhưng ngay sau khi bạn vào chỉ mục không hợp nhất hoặc sử dụng tính năng cô lập ảnh chụp nhanh hoặc bản thứ hai có thể đọc được, sự phân mảnh làm xuất hiện phần đầu xấu xí của nó và bạn cần cố gắng ngăn chặn điều đó.

Bây giờ, đừng vội vàng và nghĩ rằng bạn nên đặt hệ số lấp đầy là 70 cho tất cả các trường hợp của mình - bạn cần chọn và đặt chúng cẩn thận, như tôi đã mô tả ở trên.

Và đừng quên về SQL Sentry Fragmentation Manager, mà bạn có thể sử dụng (như một tiện ích bổ sung cho Trình tư vấn hiệu suất) để giúp tìm ra các vấn đề về phân mảnh và sau đó giải quyết chúng. Ví dụ:trên tab Chỉ mục, trước tiên bạn có thể dễ dàng sắp xếp các chỉ mục của mình theo phân mảnh cao nhất (và, nếu bạn muốn, hãy áp dụng bộ lọc cho cột đếm hàng, để bỏ qua các bảng nhỏ hơn của bạn):

Và sau đó xem liệu các chỉ mục đó có đang sử dụng hệ số lấp đầy mặc định (0%) hay có thể là hệ số lấp đầy không mặc định, có thể không phù hợp với dữ liệu và các mẫu DML của bạn. Tôi sẽ cho bạn đoán xem những cái nào trong ảnh chụp màn hình ở trên mà tôi muốn điều tra nhất. Triển khai các yếu tố lấp đầy chỉ mục thích hợp hơn là cách đơn giản nhất để giải quyết bất kỳ vấn đề nào bạn phát hiện.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL, cách cập nhật cấu trúc bảng

  2. Chất lượng dữ liệu và Tìm kiếm mờ

  3. Tạo một tập hợp hoặc trình tự không có vòng lặp - phần 1

  4. Việc cần làm (hoặc không nên làm) đối với số liệu thống kê về thời gian chờ hàng đầu

  5. Toán tử SQL không bằng với () cho người mới bắt đầu