Có thể xây dựng lại các chỉ mục gây ra hiệu suất tồi tệ hơn sau khi xây dựng lại kết thúc?

Chúng tôi có một cơ sở dữ liệu khách hàng bị phân mảnh lớn - thực tế mỗi bảng có hơn 1000 trang có độ phân mảnh> 95%. Các yếu tố điền được đặt thành các giá trị hợp lý, nhưng việc sử dụng không gian trang không ở đâu gần với hệ số điền cho hầu hết các bảng.

Đây là kết quả của việc không bảo trì được thực hiện trên cơ sở dữ liệu.

Xây dựng lại các chỉ mục bằng cách sử dụng IndexOptizing của Ola Hallengren làm giảm sự phân mảnh như mong đợi. Trên phần cứng sản xuất hiện có, hiệu suất của ứng dụng được cải thiện như mong đợi. Tất cả các số liệu tôi thường sử dụng - số liệu thống kê của khách hàng về các truy vấn nặng, thời lượng hồ sơ, quầy đọc / ghi, nhật ký ứng dụng và nhận thức của người dùng - cho thấy hiệu suất được cải thiện.

Tuy nhiên, một máy chủ cơ sở dữ liệu mới được hỗ trợ với SSD Intel PCIe đang cho thấy điều ngược lại với những gì chúng ta mong đợi. Phân mảnh cao, ứng dụng hoạt động tốt. Sau khi xây dựng lại các chỉ mục, ứng dụng hoạt động kém. Một số thao tác mất ~ 90 giờ mất ~ 6 phút. Tuy nhiên, không có số liệu nào khác xuất hiện cho thấy hệ thống đang hoạt động chậm hơn.

Đây có phải là điều mà bất cứ ai khác đã trải nghiệm?

Có, xây dựng lại các chỉ mục (đặc biệt là trên SSD) có thể gây ra hiệu suất kém hơn. Hầu hết các SSD tốc độ cao thích nhiều yêu cầu khối nhỏ hơn thay vì ít hơn, yêu cầu lớn hơn. Đây chính xác là mô hình ngược lại được ưa thích bởi truyền thống, quay gỉ.

Giả sử bạn có một cây B bị phân mảnh cao. Vì không có gì được đặt hàng trên đĩa, thông thường bạn sẽ đưa ra rất nhiều yêu cầu I / O 8KB để quét cây. Nếu bạn đã chống phân mảnh cây, thì bạn có thể nhận tới 512KB trong một yêu cầu. Những yêu cầu lớn đó sẽ có độ trễ cao hơn trên SSD, vì SSD bên trong phá vỡ nó thành các khối 8KB (không giống như ổ cứng, sẽ phát hành I / O tuần tự). Đối với nhiều trường hợp: Độ trễ đĩa cao hơn = truy vấn chậm hơn

Tất cả những gì đang được nói, xin vui lòng đảm bảo rằng bạn kiểm tra xem bạn có thực sự nhận được cùng một kế hoạch truy vấn mà bạn đã nhận được trước khi xây dựng lại không.

Cuối cùng: Trừ khi bạn thiếu dung lượng, tại sao bạn lại lãng phí thời gian DBA quý giá của mình với việc xây dựng lại chỉ mục khi bạn chạy trên SSD?

Phân mảnh cao, ứng dụng hoạt động tốt. Sau khi xây dựng lại các chỉ mục, ứng dụng hoạt động kém.

Một nguyên nhân có thể là do kích thước thay đổi (có lẽ giảm) của các cấu trúc sau khi xây dựng lại có nghĩa là trình tối ưu hóa đang chọn một kế hoạch khác. Một trong những yếu tố đầu vào chính cho mô hình chi phí của trình tối ưu hóa là số lượng trang mà mỗi nhà khai thác kế hoạch dự kiến ​​sẽ xử lý.

Thay đổi số lượng trang trong cấu trúc có thể dễ dàng tạo ra sự khác biệt giữa trình tối ưu hóa chọn hàm băm hoặc hợp nhất, so với chiến lược vòng lặp lồng nhau (có hoặc không có ống chỉ). Đó chỉ là một ví dụ; sự khác biệt về chi phí có thể ảnh hưởng đến tất cả các khía cạnh của sự lựa chọn kế hoạch, bao gồm cả quyết định sử dụng song song hay không.

Để tạo ra sự khác biệt về hiệu suất mà bạn đang quan sát (và cũng đang xem xét việc thiếu I / O vật lý), đây có vẻ như là lời giải thích khả dĩ nhất (giả sử bạn có thể loại bỏ thông số 'xấu' đánh hơi).

Tất cả những gì đã nói, không có chi tiết (kế hoạch lý tưởng và số liệu chi tiết cho một trường hợp duy nhất của vấn đề trước và sau khi xây dựng lại), câu hỏi hiện tại được cho là rất dựa trên quan điểm, sẽ khiến nó trở thành chủ đề cho trang web này.