Là tối ưu hóa truy vấn cơ sở dữ liệu nhận thức được sự khác biệt hiệu suất lưu trữ?

Theo tôi hiểu, trình tối ưu hóa truy vấn trong SQL Server (hoặc bất kỳ RDBMS nào khác, thực sự) không nhận thức được hiệu năng của bộ lưu trữ bên dưới cơ sở dữ liệu và sẽ đưa ra quyết định như thể tất cả lưu trữ có chi phí bằng nhau. Điều đó có chính xác không, hay có một số kiến ​​thức về hiệu suất lưu trữ được tính đến?

Trong một ví dụ hoàn toàn khó khăn, giả sử rằng các hàng trong bảng của tôi được lưu trữ trên ổ SSD trong SAN của tôi với thời gian truy cập tức thời, trong đó các chỉ mục của tôi được lưu trữ trên các ổ đĩa SAS quá tải, dẫn đến bão hòa đĩa và hàng đợi đĩa liên tục. Khi RDBMS tạo kế hoạch thực hiện, có khả năng ưu tiên quét bảng hơn so với thao tác chỉ mục (hoặc có thể là chỉ mục mỏng và tra cứu bảng liên quan, trái với chỉ mục che phủ, vì nó ít IO hơn trên các đĩa SAS)?

Tôi nghi ngờ câu trả lời chắc chắn "không phải là cơ hội tối ưu hóa thông minh hay thậm chí nhận thức được hiệu suất của đĩa", nhưng tôi chỉ muốn xem liệu có ai biết chắc chắn không. Tôi đang sử dụng SQL Server, nhưng tôi quan tâm đến bất kỳ hệ thống cơ sở dữ liệu nào.

Trình tối ưu hóa truy vấn của máy chủ Sql không xem xét các biến thể trong hiệu suất đĩa khi biên dịch gói truy vấn. Paul White cung cấp một cái nhìn tổng quan tuyệt vời về trình tối ưu hóa dựa trên chi phí của Sql Server tại đây:

https://sqlkiwi.blogspot.com/2010/09/inside-the-optimizer-plan-costing.html

Một số điểm chính là:

• Trình tối ưu hóa không cố gắng tính toán chi phí chính xác của một kế hoạch. Đó là cố gắng chọn kế hoạch với chi phí thấp nhất tương đối giữa một số lựa chọn thay thế.

• Đó là một cái nhìn đơn giản về thực tế. Nó giả định rằng một máy chủ có thể thực hiện 320 io / giây và hiệu suất cpu đã không tăng trong hơn một thập kỷ.

• Mặc dù các máy chủ ngày nay có các đặc tính hiệu năng rất khác nhau, trình tối ưu hóa vẫn thực hiện công việc thực sự tốt trong phần lớn các trường hợp.

Vậy, tại sao Microsoft không thêm một số thông tin bổ sung vào trình tối ưu hóa? Tuy nhiên, trong tương lai họ có thể, những gì có nhiều khả năng là những điều chỉnh nhỏ đối với chi phí của các trình vòng lặp riêng lẻ. Hiện tại lợi ích không có để biện minh cho nỗ lực.

Bạn có thể sử dụng các lệnh gọi dbcc không có giấy tờ để thay đổi một số giả định tối ưu hóa truy vấn. KHÔNG SỬ DỤNG NÀY TRÊN MÁY CHỦ SẢN XUẤT

DBCC SETIOWEIGHT(<multiplier>)
DBCC SETCPUWEIGHT(<multiplier>)

Cả hai đều có giá trị mặc định là 1. Chơi với chúng và xem liệu bạn có thể đưa ra các giá trị khác nhau luôn tạo ra các kế hoạch tốt hơn trong phần lớn các trường hợp hay không. Bạn sẽ thấy rằng những thay đổi nhỏ sẽ không thay đổi phần lớn các kế hoạch và những thay đổi lớn sẽ tạo ra những kế hoạch thực sự kỳ quái.

Một điểm nữa là trong khi SQL không xem xét hiệu suất của io khi biên dịch một kế hoạch, thì nó lại đáp ứng với hiệu suất của io trong quá trình thực hiện kế hoạch (hạn chế đọc trước khi đọc nếu io bị bão hòa, v.v.)

Trình tối ưu hóa truy vấn Db2 cho LUW nhận thức được các đặc tính hiệu suất phần cứng của máy đang chạy và xem xét chúng.

Cụ thể, mỗi không gian bảng có hai tham số số phản ánh hiệu năng lưu trữ bên dưới : overhead, phản ánh chi phí điều khiển I / O và thời gian tìm đĩa và thời gian trễ tính bằng mili giây và transferrate, cho biết thời gian cần thiết để chuyển một trang vùng bảng từ đĩa sang bộ nhớ.

Các tham số này có thể được chỉ định tại thời điểm tạo không gian bảng để ghi đè các giá trị mặc định có nguồn gốc heuristur.

Các tham số hiệu năng I / O, cùng với cpu_speedtham số mức trình quản lý cơ sở dữ liệu, được trình tối ưu hóa sử dụng để tính toán chi phí I / O và CPU của mỗi toán tử kế hoạch truy vấn và do đó sẽ ảnh hưởng đến kế hoạch cuối cùng được chọn. Sau đó, kịch bản của bạn sẽ hoàn toàn hợp lý trong Db2. Tương tự, trên một hệ thống có tốc độ CPU rất cao và hiệu năng đĩa cũng vậy, trình tối ưu hóa có thể thích các toán tử chuyên sâu CPU (ví dụ quét bảng cộng với sắp xếp) cho các I / O chuyên sâu hơn (ví dụ: truy cập bảng dựa trên chỉ mục).

Tôi tin rằng Db2 cho z / OS tương tự như các tài khoản hiệu năng phần cứng cơ bản, có được chúng từ lớp quản lý lưu trữ, không phải là một phần của cấu hình cơ sở dữ liệu.