Bạn sử dụng EXPLAIN và EXPLAIN ANALYZE như thế nào?

Question

Accepted Answer

**`EXPLAIN`** cho thấy **query execution plan** của PostgreSQL — cách nó sẽ chạy một truy vấn (dùng scan nào, join nào, index nào). **`EXPLAIN ANALYZE`** thực sự chạy truy vấn và cho thấy thời gian và số dòng thực tế. Đây là những công cụ chính để chẩn đoán các truy vấn chậm.

## EXPLAIN — query plan (không chạy)

```sql
EXPLAIN SELECT * FROM orders WHERE customer_id = 5;
-- cho thấy query plan: kiểu scan, chi phí ước tính, số dòng ước tính — nhưng không chạy nó
```

## EXPLAIN ANALYZE — query plan với dữ liệu thực thi THỰC TẾ

```sql
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- THỰC SỰ chạy nó → cho thấy thời gian THỰC, số dòng THỰC, và thời gian được tiêu tốn ở đâu
EXPLAIN (ANALYZE, BUFFERS) SELECT ...;   -- còn cho thấy mức sử dụng buffer/cache
```

`EXPLAIN ANALYZE` hữu ích hơn vì nó cho thấy hiệu năng *thực tế* (thời gian thực, số dòng thực) — tiết lộ truy vấn thực sự tiêu tốn thời gian ở đâu, chứ không chỉ là ước tính.

## Đọc query plan: những điều then chốt cần chú ý

```text
KIỂU SCAN (quan trọng nhất):
  Seq Scan      → QUÉT TOÀN BỘ BẢNG (đọc mọi dòng) — chậm trên bảng lớn, thường là vấn đề
  Index Scan    → dùng index để tìm dòng — nhanh
  Index Only Scan → chỉ đọc index (không chạm vào bảng) — nhanh nhất
  Bitmap Scan   → để kết hợp nhiều index / khi có nhiều dòng khớp

CẦN CHÚ Ý:
  ✗ Seq Scan trên một bảng lớn đang được lọc → có khả năng THIẾU INDEX
  ✗ Số dòng ước tính RẤT khác so với số dòng thực tế → thống kê lỗi thời (chạy ANALYZE)
  ✗ Các join tốn kém, các sort tràn xuống đĩa ("external merge")
  ✗ Node có thời gian thực tế cao nhất = điểm nghẽn
```

## Một ví dụ chẩn đoán

```sql
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Seq Scan on orders ... actual time=120ms" → quét toàn bộ, chậm

CREATE INDEX idx_orders_customer ON orders(customer_id);

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Index Scan using idx_orders_customer ... actual time=0.05ms" → đã sửa!
```

## Tại sao điều này quan trọng

`EXPLAIN` và `EXPLAIN ANALYZE` là những công cụ thiết yếu, chủ đạo để **chẩn đoán và tối ưu các truy vấn chậm** trong PostgreSQL — hiệu năng truy vấn là yếu tố then chốt với ứng dụng, và đây là cách bạn hiểu *tại sao* một truy vấn chậm và xác minh các bản sửa, nên thành thạo chúng là kiến thức quan trọng ở cấp senior cho công việc về hiệu năng database.

Giá trị cơ bản là **khả năng nhìn thấy query plan**: thay vì đoán tại sao một truy vấn chậm, `EXPLAIN ANALYZE` (vốn chạy truy vấn và cho thấy thời gian và số dòng thực) tiết lộ chính xác cách Postgres thực thi nó và thời gian được tiêu tốn ở đâu.

Điều quan trọng nhất cần nhận biết là các **kiểu scan** — đặc biệt là nhận diện một **`Seq Scan` (quét toàn bộ bảng)** trên một bảng lớn đang được lọc, vốn thường cho thấy việc **thiếu index** (vấn đề hiệu năng truy vấn phổ biến và tác động mạnh nhất), so với một **`Index Scan`** nhanh.

Hiểu cách đọc query plan (các kiểu scan, so sánh số dòng ước tính với thực tế để phát hiện thống kê lỗi thời, xác định node tốn kém nhất là điểm nghẽn, để ý các sort tràn xuống đĩa) là kỹ năng then chốt để tối ưu truy vấn.

Quy trình chẩn đoán — chạy `EXPLAIN ANALYZE`, xác định điểm nghẽn (thường là một Seq Scan), áp dụng bản sửa (thường là thêm index), và chạy lại để xác minh — là cách tiếp cận chuẩn, dựa trên đo lường để tối ưu truy vấn.

Vì các truy vấn chậm là nguyên nhân hàng đầu gây hiệu năng database kém, và vì `EXPLAIN`/`EXPLAIN ANALYZE` là *những* công cụ để chẩn đoán chúng (tiết lộ index thiếu, query plan tệ, và điểm nghẽn) và xác minh các tối ưu, thành thạo chúng là kiến thức giá trị cao, quan trọng cho hiệu năng PostgreSQL — đó là cách bạn tìm và sửa các truy vấn chậm một cách hệ thống thay vì đoán mò, một kỹ năng then chốt cho database hiệu năng cao và là chủ đề phổ biến cho công việc tối ưu database.