Tôi cũng giả sử bạn đang sử dụng Oracle. Và tôi cũng khuyên bạn nên xem trang web giải thích kế hoạch, để bắt đầu. Có rất nhiều thứ để tối ưu hóa, nhưng nó có thể học được.
Một số mẹo sau:
Đầu tiên, khi ai đó yêu cầu bạn tối ưu hóa, họ hầu như luôn tìm kiếm hiệu suất có thể chấp nhận được hơn là hiệu suất cuối cùng. Nếu bạn có thể giảm thời gian chạy của truy vấn từ 3 phút xuống 3 giây, đừng đổ mồ hôi khi giảm thời gian đó xuống 2 giây, cho đến khi bạn được yêu cầu.
Thứ hai, hãy kiểm tra nhanh để đảm bảo rằng các truy vấn bạn đang tối ưu hóa là chính xác về mặt logic. Nghe có vẻ vô lý, nhưng tôi không thể cho bạn biết số lần tôi được hỏi ý kiến về một truy vấn chạy chậm, chỉ để phát hiện ra rằng nó đôi khi đưa ra câu trả lời sai! Và hóa ra, gỡ lỗi truy vấn thường cũng giúp tăng tốc.
Đặc biệt, hãy tìm cụm từ "Tham gia Descartes" trong kế hoạch giải thích. Nếu bạn nhìn thấy nó ở đó, rất có thể bạn đã tìm thấy một sự tham gia cacte không chủ ý. Mô hình thông thường cho phép nối cacte không chủ ý là mệnh đề FROM liệt kê các bảng được phân tách bằng dấu phẩy và các điều kiện nối nằm trong mệnh đề WHERE. Ngoại trừ việc một trong các điều kiện nối bị thiếu, vì vậy Oracle không có lựa chọn nào khác ngoài việc thực hiện phép nối cacte. Với các bảng lớn, đây là một thảm họa về hiệu suất.
Có thể thấy phép Tham gia Đề-các trong kế hoạch giải thích nơi truy vấn đúng về mặt logic, nhưng tôi liên kết điều này với các phiên bản cũ hơn của Oracle.
Cũng tìm kiếm chỉ số hợp chất không sử dụng. Nếu cột đầu tiên của chỉ mục kết hợp không được sử dụng trong truy vấn, Oracle có thể sử dụng chỉ mục này không hiệu quả hoặc hoàn toàn không. Hãy để tôi đưa ra một ví dụ:
Truy vấn là:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(DBMS không phải là Oracle, vì vậy cú pháp khác và tôi đã quên cú pháp ban đầu).
Xem nhanh các chỉ mục cho thấy chỉ mục về Khách hàng với các cột (Quốc gia, Tiểu bang, Mã ZipCode) theo thứ tự đó. Tôi đã thay đổi truy vấn thành đọc
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
và bây giờ nó chạy trong khoảng 6 giây thay vì khoảng 6 phút, bởi vì trình tối ưu hóa đã có thể sử dụng chỉ mục để tạo lợi thế tốt. Tôi đã hỏi các nhà lập trình ứng dụng tại sao họ lại bỏ qua quốc gia khỏi tiêu chí và đây là câu trả lời của họ:họ biết rằng tất cả các địa chỉ đều có quốc gia bằng 'USA' vì vậy họ nghĩ rằng họ có thể tăng tốc truy vấn bằng cách loại bỏ tiêu chí đó!
Thật không may, việc tối ưu hóa truy xuất cơ sở dữ liệu không thực sự giống như việc loại bỏ micro giây trong thời gian tính toán. Nó liên quan đến việc hiểu thiết kế cơ sở dữ liệu, đặc biệt là các chỉ mục và ít nhất là tổng quan về cách trình tối ưu hóa thực hiện công việc của nó.
Nói chung, bạn sẽ nhận được kết quả tốt hơn từ trình tối ưu hóa khi bạn học cách cộng tác với nó thay vì cố gắng vượt qua nó.
Chúc bạn may mắn đạt được tốc độ tối ưu hóa!
