您如何使用 EXPLAIN 和 EXPLAIN ANALYZE？

Question

Accepted Answer

**`EXPLAIN`** 显示 PostgreSQL 的 **query execution plan**——它将如何运行查询（使用哪些扫描、连接、索引）。**`EXPLAIN ANALYZE`** 实际运行查询并显示真实的耗时和行数。这些是诊断慢查询的主要工具。

## EXPLAIN — 计划（不运行）

```sql
EXPLAIN SELECT * FROM orders WHERE customer_id = 5;
-- shows the PLAN: scan type, estimated cost, estimated rows — but doesn't run it
```

## EXPLAIN ANALYZE — 计划加上真实执行数据

```sql
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- ACTUALLY runs it → shows REAL time, ACTUAL rows, and where time was spent
EXPLAIN (ANALYZE, BUFFERS) SELECT ...;   -- also shows buffer/cache usage
```

`EXPLAIN ANALYZE` 更有用，因为它显示 *实际的* 性能（真实耗时、真实行数）——揭示查询真正花费时间的地方，而不仅仅是估计值。

## 读取计划：要查找的关键内容

```text
SCAN TYPES (most important):
  Seq Scan      → FULL TABLE SCAN (reads every row) — slow on big tables, often the problem
  Index Scan    → uses an index to find rows — fast
  Index Only Scan → reads only the index (doesn't touch the table) — fastest
  Bitmap Scan   → for combining indexes / many matches

WATCH FOR:
  ✗ Seq Scan on a large table being filtered → likely a MISSING INDEX
  ✗ Estimated rows VERY different from actual rows → outdated statistics (run ANALYZE)
  ✗ Expensive joins, sorts spilling to disk ("external merge")
  ✗ The node with the highest actual time = the bottleneck
```

## 诊断示例

```sql
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Seq Scan on orders ... actual time=120ms" → a full scan, slow

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" → fixed!
```

## 为什么这很重要

`EXPLAIN` 和 `EXPLAIN ANALYZE` 是 PostgreSQL 中用于 **诊断和优化慢查询** 的必要工具——查询性能对应用程序至关重要，这些工具让您能够理解查询*为什么*很慢，并验证修复效果，因此掌握它们对数据库性能工作是重要的高级知识。

其基本价值是 **对执行计划的可见性**：`EXPLAIN ANALYZE`（运行查询并显示真实耗时和行数）不再是猜测查询为什么慢，而是精确地揭示 Postgres 如何执行它以及时间花在哪里。

most important things to recognize are the **scan types** — 特别是在大型筛选表上识别 **`Seq Scan`（全表扫描）**，这通常表示 **缺少索引**（最常见且影响最大的查询性能问题），相比之下快速的 **`Index Scan`** 则要好得多。

Learning to read the plan（scan types、比较估计行数与实际行数来发现过时统计、识别最昂贵节点作为瓶颈、监视磁盘溢出排序）是查询优化的关键技能。

诊断工作流程——运行 `EXPLAIN ANALYZE`、识别瓶颈（通常是 Seq Scan）、应用修复（通常是添加索引）、重新运行以验证——是查询优化的标准、基于测量的方法。

由于慢查询是数据库性能不佳的主要原因，而 `EXPLAIN`/`EXPLAIN ANALYZE` 是诊断它们的 *主要* 工具（揭示缺失的索引、糟糕的计划和瓶颈）并验证优化，掌握它们是 PostgreSQL 性能的重要高价值知识——这是如何系统地查找和修复慢查询，而不是猜测，是高性能数据库的关键技能，也是数据库优化工作的常见主题。