Học cách tối ưu hóa các truy vấn SQL và hiểu các kế hoạch thực hiện - Tài nguyên?

Tôi thấy mình viết ngày càng nhiều truy vấn SQL tại nơi làm việc (chủ yếu là Oracle 11g, nhưng một số SQL Server 2005-2008) và đã bắt đầu tạo ra một số khung nhìn khá phức tạp cho phần còn lại của nhóm phân tích.

Họ chủ yếu chạy khá tốt, nhưng một số trong số họ không tốt lắm. Vì thế...

• Làm thế nào để tôi học cách điều chỉnh các truy vấn của tôi?
• Tôi có cần học cách đọc / hành động trong Kế hoạch thực hiện không?

Và ...

• Những cuốn sách / trang web nào bạn có thể đề xuất để tìm hiểu về điều chỉnh truy vấn SQL 1) nói chung 2) cụ thể cho Oracle 11g?

Chúng tôi có một số DBA tốt ở đây, nhưng chúng quá lầy để giúp chúng tôi điều chỉnh mọi truy vấn chúng tôi viết.

Hầu hết các cuốn sách mà tôi đã tìm thấy trên Amazon cho Oracle dường như đều hướng đến tối ưu hóa cơ sở dữ liệu tổng thể và / hoặc được viết cách đây 8-10 năm.

Cảm ơn vui lòng cho lời khuyên của bạn :)

Tôi muốn nói rằng học cách hiểu các kế hoạch giải thích là một kỹ năng quan trọng trong việc giúp bạn tối ưu hóa các câu lệnh SQL. Tôi đã tìm thấy cuốn sách của Christian Antognini, Khắc phục sự cố Oracle Performance , rất hữu ích trong việc chi tiết cách thức hoạt động của chúng, cũng như giải thích cách tiếp cận tối ưu hóa cơ sở dữ liệu. Mặc dù đã vài tuổi, bạn vẫn sẽ học được nhiều điều vẫn có liên quan từ nó.

Nếu bạn tiến bộ hơn, bạn có thể xem các cuốn sách của Jonathan Lewis, nhưng những cuốn này có chiều sâu hơn nên có lẽ không phải là điểm khởi đầu tốt. Oracle Fund dựa trên chi phí hiện nay khá cũ, nhưng phần lớn vẫn còn có liên quan. Tôi chưa đọc Oracle Core: Essential Internals để khắc phục sự cố , nhưng nó đã nhận được đánh giá tốt từ cộng đồng Oracle.

Như bạn đang trên 11g, nếu bạn có các truy vấn mất hơn một vài giây, tôi chắc chắn khuyên bạn nên xem màn hình SQL thời gian thực (giả sử bạn được cấp phép phù hợp). Như tên cho thấy, nó cho thấy tiến trình của một câu lệnh SQL trong thời gian thực, chia nhỏ thời gian mỗi thao tác đã thực hiện với các chi tiết về các hàng được tìm nạp cho đến nay. Nó cũng giữ chi tiết về các truy vấn được thực hiện gần đây trong một thời gian ngắn để có thể thấy các thay đổi của bạn ảnh hưởng đến một tuyên bố như thế nào.

Tài liệu giám sát SQL của Oracle: http://docs.oracle.com/cd/E11882_01/server.112/e16638/instance_tune.htmlm#PFGRF94543

Học cách điều chỉnh các truy vấn là điều sẽ mất thời gian và thực hành. Một vài điều tôi đã học được:

• Viết truy vấn để tìm nạp càng ít hàng càng sớm càng tốt (ví dụ: bạn không muốn quét toàn bộ bảng 10 triệu hàng nếu bạn chỉ cần 100 hàng từ nó)
• Xác minh rằng số lượng hàng dự kiến ​​trong mỗi bước của kế hoạch giải thích (dự kiến) khớp với số hàng được trả về trong kế hoạch thực hiện thực tế. Khi đây là những đơn đặt hàng có cường độ khác nhau, có khả năng trình tối ưu hóa không chọn phương án "tốt nhất".
• Hiểu các nguyên tắc lập chỉ mục tốt: cách chúng hoạt động và khi nào nên / không nên sử dụng khi thực hiện truy vấn ( Richard Foote có một blog rất sâu thảo luận về các chỉ mục trong Oracle)

Hầu hết bạn sẽ học bằng cách viết các truy vấn, xem xét các kế hoạch giải thích (dự kiến) và so sánh các kế hoạch này với các kế hoạch thực hiện thực tế (thông qua truy tìm truy vấn hoặc sử dụng trình giám sát SQL). Sau đó viết lại truy vấn, thêm / xóa chỉ mục, v.v. và xem nó ảnh hưởng đến kế hoạch và thời gian thực hiện như thế nào

Khi bạn đang tìm kiếm thông tin cụ thể của Oracle, tôi muốn giới thiệu blog Ask Tom tại Oracle. Nói chung, tôi nghĩ rằng bạn sẽ tìm thấy lời khuyên là không điều chỉnh truy vấn. Bạn sẽ nhận được lời khuyên tốt về cách viết truy vấn mà trình tối ưu hóa có thể tối ưu hóa. Tài liệu của Oracle cũng trực tuyến và tôi thường tìm thông tin cập nhật về Oracle. Tôi chưa làm việc với SQLServer vì vậy tôi không có bất kỳ đề xuất nào cho nó.

Tôi đã không thấy nhiều điều mới trong lĩnh vực tối ưu hóa các truy vấn trong vài năm qua. Sự thay đổi lớn là sự phản đối của trình tối ưu hóa dựa trên quy tắc, điều mà tôi hầu như không thể nhớ được khi làm việc với. Tuy nhiên, tôi hiểu SQLServer vẫn sử dụng trình tối ưu hóa dựa trên quy tắc, vì vậy việc hiểu các quy tắc của nó có thể giúp ích.

Một công cụ nơi bạn có thể chỉnh sửa một truy vấn, thực hiện nó và tạo một kế hoạch giải thích giúp hiểu được những thay đổi nào mang lại cho bạn một truy vấn hoạt động tốt. Tôi đã có kết quả tốt với AquaData Studio, và thực sự thích khung cảnh cây của nó. Nhà phát triển SQL cũng nên làm như vậy.

Như với bất kỳ tối ưu hóa nào, bạn cần có dữ liệu định lượng về hiệu suất của nó. Sau đó, bạn có thể xác định nếu bạn thực sự đã tối ưu hóa nó.

Cách tối ưu hóa truy vấn phụ thuộc một phần vào cách trình phân tích cú pháp xây dựng và tối ưu hóa truy vấn. Ở mức độ lớn hơn, nó phụ thuộc vào việc phân phối dữ liệu bạn đang truy vấn. Trong cơ sở dữ liệu Oracle nếu tập kết quả chiếm từ bốn phần trăm trở lên của bảng và được phân phối ngẫu nhiên, quét bảng thường nhanh hơn chỉ mục.

Tôi đã làm việc để tối ưu hóa các truy vấn cho một nhóm các nhà phát triển. Chỉ hai hoặc ba truy vấn một năm yêu cầu tối ưu hóa nghiêm trọng. Hầu hết các truy vấn đủ đơn giản để họ không cần tối ưu hóa. Phần còn lại thường có thể được xử lý bằng cách thêm các đường dẫn tham gia bị thiếu.

Đối với Oracle, có ba cài đặt có thể điều chỉnh có thể ảnh hưởng đáng kể đến hiệu suất. Chi phí cho việc tra cứu chỉ mục và dữ liệu tương tác để thay đổi các điều kiện theo đó một chỉ mục trong hoặc sẽ không được sử dụng. Hai cái này có thể được điều chỉnh trên cơ sở mỗi phiên. Mặc định thường không tối ưu. Giá trị khác kiểm soát số lượng thay thế mà trình tối ưu hóa sẽ thử. Tăng giá trị này thường giúp.

Tối ưu hóa bị ảnh hưởng đáng kể bởi phân phối dữ liệu và khối lượng. Khi tối ưu hóa, tốt nhất nên sử dụng một bản sao của cơ sở dữ liệu sản xuất hoặc ít nhất là một cơ sở dữ liệu có cùng phân phối dữ liệu và khối lượng. Tôi đã phá vỡ nghiêm trọng môi trường thử nghiệm, tối ưu hóa một truy vấn cho cơ sở dữ liệu đơn hàng sản xuất. Các cơ sở dữ liệu thử nghiệm và phát triển có phân phối dữ liệu khác nhau đáng kể khiến truy vấn không thành công ngay cả với dữ liệu ít hơn đáng kể.