Có ổn không khi có hệ số lấp đầy là 100 trên chỉ mục được nhóm trên cột ID?

Vì vậy, tôi có một bảng với một chỉ mục được nhóm trên một cột ID (là cột tăng tự động) trong SQL Server.

Có ổn không khi có hệ số lấp đầy là 100 vì điều này vì dữ liệu sẽ luôn được ghi bằng ID mới nhất tiếp theo? Sẽ có vấn đề gì nếu các cột khác trong bảng này được cập nhật rất nhiều cho các ID hiện có?

Ngoài ra, làm thế nào để xóa tác động đến sự phân mảnh của bảng?

Trong hầu hết các trường hợp, bạn làm muốn có một FILLFACTORsố 100. Chỉ trong trường hợp đặc biệt bạn sẽ muốn hạ thấp giá trị đó. Các cập nhật chỉ gây ra sự chia tách trang nếu chúng tăng kích thước của hàng sao cho nó vẫn không vừa trên cùng một trang dữ liệu. Xóa ở đây và không có vấn đề trong cả hai trường hợp. Trong mọi trường hợp, bạn cần thực hiện bảo trì chỉ mục thường xuyên và REBUILDchỉ mục được nhóm khi phân mảnh vượt quá một giới hạn nhất định. Rebuild sẽ sắp xếp lại tất cả các dữ liệu theo thứ tự lý tưởng, do đó, nó sẽ điền vào các khoảng trống còn lại bởi các DELETEhoạt động và UPDATEthao tác gây ra sự phân tách trang nơi vẫn còn chỗ trống trên các trang dữ liệu cũ và / hoặc mới.

Rất nhiều xóa có thể để lại các trang trống và do đó một số phân mảnh, nhưng sử dụng một số thấp hơn FILLFACTORsẽ không giúp được gì ở đó. Và trên thực tế, tùy thuộc vào những hàng nào đang bị xóa, bạn có thể tăng phân mảnh trang trống vì sẽ có ít hàng hơn trên mỗi trang dữ liệu ở vị trí đầu tiên.

Nhưng hãy ghi nhớ:

• Sử dụng FILLFACTOR100 không có nghĩa là 100% dung lượng được sử dụng. Hàng phù hợp với trang dữ liệu miễn là có không gian cho toàn bộ hàng. Nếu bạn còn 100 byte và có một hàng 105 byte để thêm, nó không thể phù hợp ở đó. Nhưng vẫn còn không gian cho một bản cập nhật của cột có chiều dài thay đổi để tăng thêm 50 byte.
• Khi bạn đặt FILLFACTORthành dưới 100, bạn đang đặt trước không gian trên tất cả các trang dữ liệu, không chỉ các trang sẽ được cập nhật. Trừ khi bạn có một mẫu sử dụng phân phối đồng đều các bản cập nhật trên toàn bộ phạm vi của bảng / chỉ mục, tại sao lại dành chỗ trên các trang dữ liệu chứa các hàng "cũ" không được cập nhật? Điều đó chỉ làm chậm các truy vấn trên toàn bộ chỉ mục / bảng với hy vọng rằng một số trang dữ liệu mới hơn (nghĩa là các hàng có nhiều khả năng được cập nhật) sẽ không bị chia trang sớm nhất khi sử dụng FILLFACTOR100.

• Xem xét kích thước của các hàng của bạn và số lượng sẽ phù hợp với một trang dữ liệu khi FILLFACTOR100 và bao nhiêu sẽ phù hợp với một trang dữ liệu với mức thấp hơn FILLFACTORnhư 90 hoặc thậm chí 80. Nếu bạn có hàng rộng 500 - 1000 byte, sự khác biệt giữa các FILLFACTORgiá trị khác nhau có thể chỉ là một hoặc một vài hàng. Những loại cập nhật đang xảy ra? Nếu các bản cập nhật là các cột có độ dài cố định, thì đây thậm chí không phải là vấn đề. Đối với các cột có độ dài thay đổi, chúng có thể tăng kích thước thêm 100 - 500 byte không?

  Có một số yếu tố để xem xét ở đây là thực sự thực tế: nếu, trong một ngày hoặc một tuần (bao lâu giữa các REBUILDhoạt động?) Các UPDATEhoạt động liên tiếp trên các hàng sắp xếp gần nhau sẽ mở rộng kích thước và gây ra nhiều lần chia trang, sau đó đang hoãn việc chia trang đó vài giờ hoặc một ngày thực sự có giá trị tác động của việc lưu trữ không gian đó trên toàn bộ bảng / chỉ mục để nó chiếm nhiều không gian đĩa, không gian trong bộ nhớ (ví dụ: Bộ đệm), giúp sao lưu lớn hơn, mất nhiều thời gian hơn đọc từ đĩa vào Bộ đệm, mất nhiều thời gian hơn để bảo trì chỉ mục, v.v?

• Phân mảnh ảnh hưởng xấu đến các truy vấn phạm vi, không phải các truy vấn đơn lẻ. Nếu bạn đang tìm nạp các hàng riêng lẻ (hoặc tìm các hàng được cập nhật hoặc xóa), bạn có thể sẽ không thấy tác động của sự phân mảnh, ít nhất là cho đến khi nó thực sự xấu, nhưng có thể không hoàn toàn.

Như với nhiều / hầu hết các quyết định kỹ thuật, có nhiều kỹ thuật khác nhau ảnh hưởng đến cách tiếp cận "tốt nhất" hoặc "tối ưu". Vì vậy, bạn thực sự cần phải xem xét kích thước tối đa của hàng, nếu các cập nhật sẽ xảy ra với các cột có độ dài thay đổi, nếu hoạt động cập nhật sẽ chủ yếu trải đều trên bảng / chỉ mục hoặc giới hạn ở một phân đoạn "gần đây" của nó , v.v. Tôi đã làm việc ở những nơi mà chính sách dành cho tất cả các bảng có FILLFACTOR80 điểm và đó là một thực tế điên rồ (và vô trách nhiệm) khi chúng tôi sử dụng IDENTITYcác cột cho các chỉ mục được nhóm (thường là PK) và dữ liệu "cũ" hơn từng được cập nhật. khôi phục các hoạt động mất nhiều thời gian hơn!) và nhai thêm bộ nhớ, điều này buộc các kế hoạch được lưu trong bộ nhớ cache bị xóa hoặc các trang dữ liệu được lưu trong bộ nhớ cache (tức là Tuổi thọ của Trang khá thấp).

ERGO: Bắt đầu với 100 và thử nghiệm giảm số lượng nhỏ NẾU / KHI bạn nghĩ rằng việc tối ưu hóa có thể được bảo đảm (nghĩa là nếu bạn thấy rằng sự phân mảnh trên một bảng cụ thể đang tăng lên mức cao hơn giữa các lần xây dựng lại VÀ điều đó cũng gây ra sự suy giảm hiệu suất!).

Bạn sẽ muốn giữ hệ số lấp đầy mặc định ở mức 100 trừ khi bạn có độ phân mảnh cao. Xin lưu ý rằng nếu bảng được giữ hoàn toàn trong bộ nhớ, tác động của hệ số lấp đầy của bạn sẽ giảm đi rất nhiều. Đừng cho rằng nếu bản ghi chỉ đơn giản là được cập nhật thì nó sẽ nằm gọn trong không gian. Nếu bản ghi được cập nhật với nhiều thông tin hơn mức phù hợp với bản ghi trước đó (và trang đã đầy), nó sẽ phải chuyển nó sang trang khác.

Đọc điều này để hiểu làm thế nào xóa thực sự có thể gây ra sự phân mảnh.