Khi cố gắng hiểu cách một câu lệnh SQL đang thực thi, đôi khi bạn nên xem kế hoạch giải thích. Quá trình mà người ta phải trải qua trong việc diễn giải (tạo ra ý nghĩa) của một kế hoạch giải thích là gì? Điều gì phải nổi bật là, "Ồ, cái này đang hoạt động hiệu quả?" so với "Ồ không, không đúng."
Câu trả lời:
Tôi rùng mình bất cứ khi nào tôi nhìn thấy các bình luận rằng toàn bộ bảng là xấu và truy cập chỉ mục là tốt. Quét toàn bộ bảng, quét phạm vi chỉ mục, quét chỉ mục đầy đủ nhanh, vòng lặp lồng nhau, liên kết hợp nhất, liên kết băm, v.v. chỉ đơn giản là cơ chế truy cập mà nhà phân tích phải hiểu và kết hợp với kiến thức về cấu trúc cơ sở dữ liệu và mục đích của truy vấn trong để đạt được bất kỳ kết luận có ý nghĩa nào.
Quét toàn bộ chỉ đơn giản là cách hiệu quả nhất để đọc một tỷ lệ lớn các khối của phân đoạn dữ liệu (bảng hoặc phân vùng bảng (con)) và, mặc dù nó thường có thể chỉ ra một vấn đề về hiệu suất, nhưng đó chỉ là trong ngữ cảnh về việc liệu đó có phải là một cơ chế hiệu quả để đạt được các mục tiêu của truy vấn hay không. Nói như một kho dữ liệu và anh chàng BI, lá cờ cảnh báo số một của tôi về hiệu suất là một phương pháp truy cập dựa trên chỉ mục và một vòng lặp lồng nhau.
Vì vậy, đối với cơ chế của cách đọc một gói giải thích, tài liệu Oracle là một hướng dẫn tốt: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009
Hãy đọc kỹ Hướng dẫn Điều chỉnh Hiệu suất.
Cũng có google cho "phản hồi về bản số", một kỹ thuật trong đó kế hoạch giải thích có thể được sử dụng để so sánh các ước tính về bản số ở các giai đoạn khác nhau trong một truy vấn với các bản số thực tế đã trải qua trong quá trình thực thi. Tôi tin rằng Wolfgang Breitling là tác giả của phương pháp này.
Vì vậy, điểm mấu chốt: hãy hiểu cơ chế truy cập. Hiểu cơ sở dữ liệu. Hiểu ý định của truy vấn. Tránh các quy tắc ngón tay cái.
Chủ đề này quá lớn để trả lời trong một câu hỏi như thế này. Bạn nên dành chút thời gian để đọc Hướng dẫn Điều chỉnh Hiệu suất của Oracle
Hai ví dụ dưới đây cho thấy quét ĐẦY ĐỦ và quét NHANH sử dụng INDEX.
Tốt nhất bạn nên tập trung vào Chi phí và Bản số của mình. Nhìn vào các ví dụ, việc sử dụng chỉ mục làm giảm Chi phí chạy truy vấn.
Nó phức tạp hơn một chút (và tôi không có xử lý 100% về nó) nhưng về cơ bản Cost là một hàm của chi phí CPU và IO, và Cardinality là số hàng mà Oracle dự kiến sẽ phân tích cú pháp. Giảm cả hai điều này là một điều tốt.
Đừng quên rằng Chi phí của một truy vấn có thể bị ảnh hưởng bởi truy vấn của bạn và mô hình tối ưu hóa của Oracle (ví dụ: COST, CHOOSE, v.v.) và tần suất bạn chạy thống kê của mình.
Ví dụ 1:
QUÉT http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b
Ví dụ 2 sử dụng Chỉ mục:
INDEX http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b
Và như đã được đề xuất, hãy coi chừng QUÉT BẢNG. Bạn thường có thể tránh những điều này.
Tìm kiếm những thứ như quét tuần tự có thể phần nào hữu ích, nhưng thực tế là ở các con số ... ngoại trừ khi các con số chỉ là ước tính! Có gì thường là xa ích hơn nhìn vào một truy vấn kế hoạch là nhìn vào thực tế thực hiện . Trong Postgres, đây là sự khác biệt giữa GIẢI THÍCH và GIẢI THÍCH PHÂN TÍCH. GIẢI THÍCH PHÂN TÍCH thực sự thực thi truy vấn và nhận thông tin thời gian thực cho mọi nút. Điều đó cho phép bạn thấy những gì đang thực sự xảy ra, thay vì những gì người lập kế hoạch nghĩ sẽ xảy ra. Nhiều khi bạn sẽ thấy rằng quét tuần tự hoàn toàn không phải là vấn đề, thay vào đó nó là thứ khác trong truy vấn.
Chìa khóa khác là xác định bước đắt tiền thực sự là gì. Nhiều công cụ đồ họa sẽ sử dụng các mũi tên có kích thước khác nhau để cho biết chi phí của các phần khác nhau của kế hoạch. Trong trường hợp đó, chỉ cần tìm các bước có mũi tên mảnh đi vào và mũi tên dày rời đi. Nếu không sử dụng GUI, bạn sẽ cần nhìn vào các con số và tìm kiếm vị trí mà chúng đột nhiên lớn hơn nhiều. Với một chút thực hành, nó trở nên khá dễ dàng để chọn ra các khu vực có vấn đề.
Thực sự đối với những vấn đề như thế này, điều tốt nhất nên làm là ASKTOM . Đặc biệt câu trả lời của anh ấy cho câu hỏi đó chứa các liên kết đến tài liệu Oracle trực tuyến, nơi rất nhiều loại quy tắc đó được giải thích.
Một điều cần ghi nhớ, đó là các kế hoạch giải thích thực sự là những dự đoán tốt nhất.
Sẽ là một ý kiến hay nếu bạn học cách sử dụng sqlplus và thử nghiệm với lệnh AUTOTRACE. Với một số con số khó, bạn thường có thể đưa ra quyết định tốt hơn.
Nhưng bạn nên ASKTOM. Anh ấy biết tất cả về nó :)
Kết quả của phần giải thích cho bạn biết mỗi bước đã thực hiện trong bao lâu. Điều đầu tiên là tìm các bước đã thực hiện trong một thời gian dài và hiểu ý nghĩa của chúng. Những thứ như quét tuần tự cho bạn biết rằng bạn cần chỉ mục tốt hơn - chủ yếu là vấn đề nghiên cứu cơ sở dữ liệu và trải nghiệm cụ thể của bạn.
Một câu "Ồ không, không đúng" thường ở dạng quét bảng . Quét bảng không sử dụng bất kỳ chỉ mục đặc biệt nào và có thể góp phần xóa mọi thứ hữu ích trong bộ nhớ đệm. Ví dụ, trong postgreSQL, bạn sẽ thấy nó trông như thế này.
Seq Scan on my_table (cost=0.00..15558.92 rows=620092 width=78)Đôi khi, việc quét bảng là lý tưởng để sử dụng một chỉ mục để truy vấn các hàng. Tuy nhiên, đây là một trong những mẫu cờ đỏ sao vàng mà bạn đang tìm kiếm.
Về cơ bản, bạn xem xét từng thao tác và xem liệu các thao tác có "hợp lý" hay không khi bạn biết về cách nó có thể hoạt động.
Ví dụ: nếu bạn đang kết hợp hai bảng, A và B trên các cột C và D tương ứng của chúng (AC = BD), và kế hoạch của bạn hiển thị quét chỉ mục theo nhóm (thuật ngữ SQL Server - không chắc chắn về thuật ngữ tiên tri) trên bảng A, sau đó là một vòng lặp lồng nhau tham gia vào một loạt các tìm kiếm chỉ mục được phân cụm trên bảng B, bạn có thể nghĩ rằng đã có vấn đề. Trong trường hợp đó, bạn có thể mong đợi công cụ thực hiện một cặp quét chỉ mục (trên các chỉ mục trên các cột được kết hợp) sau đó là kết hợp hợp nhất. Việc điều tra thêm có thể tiết lộ số liệu thống kê không hợp lệ khiến trình tối ưu hóa chọn mẫu kết hợp đó hoặc một chỉ mục không thực sự tồn tại.
nhìn vào phần trăm thời gian dành cho mỗi tiểu mục của kế hoạch và xem xét động cơ đang làm gì. ví dụ: nếu nó đang quét một bảng, hãy xem xét đặt một chỉ mục vào (các) trường đang quét
Tôi chủ yếu tìm kiếm chỉ mục hoặc quét bảng. Điều này thường cho tôi biết rằng tôi đang thiếu một chỉ mục trên một cột quan trọng trong câu lệnh where hoặc câu lệnh tham gia.
Từ http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx :
Nếu bạn thấy bất kỳ điều nào sau đây trong một kế hoạch thực thi, bạn nên xem xét chúng là dấu hiệu cảnh báo và điều tra chúng để biết các vấn đề về hiệu suất tiềm ẩn. Mỗi người trong số họ đều ít hơn lý tưởng từ góc độ hiệu suất.
* Index or table scans: May indicate a need for better or additional indexes. * Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement. * Filter: Remove any functions in the WHERE clause, don't include wiews in your Transact-SQL code, may need additional indexes. * Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently?Không phải lúc nào bạn cũng có thể tránh được những điều này, nhưng bạn càng tránh được chúng thì hiệu suất truy vấn càng nhanh.
(bạn có thể cũng muốn đọc chi tiết:
Bảng quét một số bảng lớn
Sử dụng một chỉ mục duy nhất Chỉ
mục bao gồm tất cả các trường bắt buộc
Trong khoảng 90% các vấn đề về hiệu suất mà tôi đã thấy, chiến thắng dễ dàng nhất là chia một truy vấn có rất nhiều (4 hoặc nhiều hơn) bảng thành 2 truy vấn nhỏ hơn và một bảng tạm thời.