Bài 5: Phân tích Execution Plan – Bí kíp đọc hiểu và tối ưu hóa SQL từ gốc

Dưới đây là nội dung chi tiết cho Bài 5: Phân tích Execution Plan – Bí kíp đọc hiểu và tối ưu hóa SQL từ gốc, phân tích sâu cơ chế hoạt động của database và cách tận dụng Execution Plan để tối ưu hóa triệt để:

---

Giải mã "bộ não" của database để tối ưu query hiệu năng cao

---

1. Execution Plan là gì? Tại sao nó quan trọng?

1.1. Định nghĩa

• Execution Plan (Kế hoạch thực thi): Là cách database quyết định thực thi một query, bao gồm:

  • Thứ tự truy cập bảng.

  • Phương pháp join.

  • Sử dụng index hay full scan.

  • Chi phí ước tính (CPU, I/O, memory).

1.2. Tại sao cần phân tích?

• Phát hiện "nút thắt cổ chai": Xác định bước tốn nhiều tài nguyên nhất.

• Hiểu cách database tối ưu: Đôi khi logic query đúng nhưng Execution Plan không hiệu quả.

• Tránh phỏng đoán: Tối ưu dựa trên dữ liệu thực tế, không dựa trên cảm tính.

---

2. Cơ chế sinh Execution Plan

2.1. Các bước tối ưu hóa của Database

1. Parsing: Kiểm tra cú pháp query.

2. Binding: Xác định đối tượng (bảng, cột).

3. Optimization:

   • Cost-Based Optimizer (CBO): Tính toán chi phí của các phương án thực thi (dựa trên thống kê dữ liệu).

   • Rule-Based Optimizer (RBO): Áp dụng quy tắc cứng (hiếm dùng trong database hiện đại).

4. Execution: Chạy theo plan đã chọn.

2.2. Yếu tố ảnh hưởng đến Execution Plan

• Thống kê dữ liệu (Statistics): Số lượng rows, phân phối giá trị, histogram.

• Cấu hình database: Join buffer size, work memory, parallel workers.

• Index và Constraints: Loại index, uniqueness.

---

3. Đọc hiểu Execution Plan qua ví dụ thực tế

3.1. Ví dụ trên PostgreSQL (EXPLAIN ANALYZE)

Query:

EXPLAIN ANALYZE  
SELECT * FROM orders  
WHERE customer_id IN (  
  SELECT id FROM customers WHERE country = 'US'  
);

Kết quả:

QUERY PLAN  
------------------------------------------------------------------  
Nested Loop  (cost=1000.00..20000.00 rows=1000 width=200)  
  ->  Seq Scan on customers  (cost=0.00..1000.00 rows=100 width=4)  
        Filter: (country = 'US')  
  ->  Index Scan using idx_orders_customer_id on orders  (cost=1000.00..19000.00 rows=10 width=200)  
        Index Cond: (customer_id = customers.id)  
Planning Time: 0.2 ms  
Execution Time: 50.0 ms

Giải mã từng thành phần:

• Nested Loop: Phương pháp join (lồng vòng lặp).

• Seq Scan (Full Table Scan): Quét toàn bộ bảng customers (tốn 1000 đơn vị cost).

• Index Scan: Sử dụng index idx_orders_customer_id để tìm orders theo customer_id.

• Cost: [ước tính ban đầu]..[ước tính cuối] (đơn vị tương đối).

• Rows: Số rows ước tính xử lý.

• Width: Kích thước trung bình mỗi row (bytes).

3.2. Phân tích các phép toán phổ biến

---

4. Case Study: Tối ưu hóa query chậm dựa trên Execution Plan

4.1. Bối cảnh

• Query:

    SELECT * FROM orders  
    WHERE order_date BETWEEN '2023-01-01' AND '2023-12-31'  
    ORDER BY total_amount DESC  
    LIMIT 100;
  

• Thống kê:

  • Bảng orders: 10 triệu rows.

  • Index trên order_date và total_amount.

4.2. Execution Plan gốc (Chưa tối ưu)

QUERY PLAN  
------------------------------------------------------------------  
Limit  (cost=100000.00..100000.50 rows=100 width=200)  
  ->  Sort  (cost=100000.00..120000.00 rows=8000000 width=200)  
        Sort Key: total_amount DESC  
        ->  Seq Scan on orders  (cost=0.00..150000.00 rows=8000000 width=200)  
              Filter: (order_date BETWEEN '2023-01-01' AND '2023-12-31')  
Planning Time: 0.1 ms  
Execution Time: 4500.0 ms

Phân tích vấn đề:

1. Seq Scan trên orders: Không sử dụng index order_date.

2. Sort toàn bộ 8 triệu rows: Tốn CPU và memory.

4.3. Tối ưu hóa

Bước 1: Thêm Composite Index để kết hợp điều kiện WHERE và ORDER BY:

CREATE INDEX idx_orders_date_amount ON orders(order_date, total_amount DESC);

Bước 2: Kiểm tra lại Execution Plan:

QUERY PLAN  
------------------------------------------------------------------  
Limit  (cost=0.42..50.75 rows=100 width=200)  
  ->  Index Scan using idx_orders_date_amount on orders  (cost=0.42..400000.00 rows=8000000 width=200)  
        Index Cond: (order_date BETWEEN '2023-01-01' AND '2023-12-31')  
Planning Time: 0.3 ms  
Execution Time: 12.0 ms

Kết quả:

• Execution Time giảm từ 4500ms → 12ms (cải thiện 375 lần).

• Lý do:

  • Index cung cấp dữ liệu đã lọc và sắp xếp sẵn.

  • Không cần Sort và tránh Full Scan.

---

5. Công cụ hỗ trợ phân tích nâng cao

5.1. PostgreSQL:

• EXPLAIN (ANALYZE, BUFFERS): Hiển thị chi tiết cache và I/O.

• EXPLAIN (FORMAT JSON): Xuất plan dạng JSON để phân tích bằng tool.

5.2. MySQL:

• EXPLAIN FORMAT=TREE: Hiển thị plan dạng cây (MySQL 8.0+).

• Optimizer Trace: Theo dõi quyết định của Optimizer.

5.3. SQL Server:

• SET SHOWPLAN_ALL ON: Xuất thông tin chi tiết plan.

• Dynamic Management Views (DMVs): Theo dõi hiệu năng thực thi.

---

6. Bài tập thực hành

Phân tích và tối ưu query sau dựa trên Execution Plan:

SELECT 
  c.customer_name, 
  COUNT(o.order_id) AS total_orders  
FROM customers c  
LEFT JOIN orders o ON c.id = o.customer_id  
WHERE c.country = 'US'  
GROUP BY c.customer_name  
HAVING COUNT(o.order_id) > 10  
ORDER BY total_orders DESC;

Gợi ý tối ưu:

1. Thêm index trên customers.country và orders.customer_id.

2. Thay đổi JOIN thành Hash Aggregation nếu phù hợp.

3. Kiểm tra xem Materialized View có áp dụng được không.

---

7. Tổng kết

• Execution Plan là "tấm bản đồ" quan trọng nhất để debug query chậm.

• Hiểu sâu các phép toán (Scan, Join, Sort) giúp đưa ra quyết định tối ưu đúng trọng tâm.

• Luôn kết hợp:

  • Thống kê dữ liệu chính xác.

  • Index phù hợp với điều kiện truy vấn.

  • Cấu hình database tối ưu.

Thành thạo Execution Plan giúp bạn "nhìn thấu" database và trở thành cao thủ tối ưu hóa!

---

Preview bài tiếp theo:
Bài 6: Tránh SELECT \ – Tác hại không ngờ và cách viết query "sạch".*