EXPLAIN 命令用于显示 PostgreSQL 执行查询的计划。它提供了查询的执行步骤、每个步骤的执行顺序以及预计的资源消耗。这有助于识别和优化性能瓶颈。EXPLAIN 可以与 ANALYZE 结合使用，以显示实际执行时的详细统计信息。
EXPLAIN [ANALYZE] [VERBOSE] query;
-
ANALYZE：实际执行查询并显示实际的运行时间和行数。 -
VERBOSE：显示更详细的信息。
EXPLAIN SELECT * FROM orders WHERE customer_id = 123 AND order_date > '2023-01-01';
Seq Scan on orders (cost=0.00..431.00 rows=21 width=58)
Filter: ((customer_id = 123) AND (order_date > '2023-01-01'::date))
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 123 AND order_date > '2023-01-01';
Seq Scan on orders (cost=0.00..431.00 rows=21 width=58) (actual time=0.016..0.021 rows=1 loops=1)
Filter: ((customer_id = 123) AND (order_date > '2023-01-01'::date))
Rows Removed by Filter: 5
Planning Time: 0.150 ms
Execution Time: 0.035 ms
输出说明
EXPLAIN SELECT *
FROM tenk1 t1, tenk2 t2
WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
QUERY PLAN
------------------------------------------------------------------------------------------
Hash Join (cost=230.47..713.98 rows=101 width=488)
Hash Cond: (t2.unique2 = t1.unique2)
-> Seq Scan on tenk2 t2 (cost=0.00..445.00 rows=10000 width=244)
-> Hash (cost=229.20..229.20 rows=101 width=244)
-> Bitmap Heap Scan on tenk1 t1 (cost=5.07..229.20 rows=101 width=244)
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0)
Index Cond: (unique1 < 100)
https://www.postgresql.org/docs/current/using-explain.html
输出一个查询计划的树结构，最底层的是扫面结点，子节点先执行，然后执行上层节点，最上层的节点是语句的总体解释。每个节点使用 -> 表示其层级关系和执行顺序
-
Seq Scan on orders：表示对
orders表进行顺序扫描。 -
cost=0.00..431.00：表示预计的启动成本（
0.00）和总成本（431.00）。- 启动成本：从开始执行到输出第一行的成本。（比如排序，或者过滤的消耗）
- 总成本：处理完所有行的总成本。
-
rows=21：估计的返回行数。
返回的行数是预估的，所以不一定准确， 数据库会对数据进行采样预估 - width=58：每行的字节数。
- Filter：应用的过滤条件。
-
actual time=0.016..0.021：实际开始时间（
0.016ms）和结束时间（0.021ms）。 - rows=1：实际返回的行数。
- loops=1：执行的循环次数。
- Rows Removed by Filter: 5：被过滤条件排除的行数。
- Planning Time：查询计划生成所需时间。
- Execution Time：实际查询执行所需时间。
常见的节点操作类型
扫描
Seq Scan：逐行扫描整个表，检查每一行是否符合查询条件。
适用于小表或无索引的查询。
全表扫描，可能会较慢，对于大表特别不高效。
Index Scan：使用索引扫描，适用于有索引的列。
适用于有索引的表。
更快的查询速度，因为只扫描符合条件的部分数据。
会连接原来的表数据
对于范围查询，Index Scan会先查找范围的起始值，然后顺序读取所有符合条件的条目。
Index Only Scan：仅使用索引数据，无需访问表数据。
Bitmap Heap Scan：结合位图索引扫描和堆扫描。
Bitmap Index Scan：首先，数据库系统使用位图索引扫描（Bitmap Index Scan）来查找符合查询条件的行的位图。这些位图是索引的“位图表示”，标识了哪些索引项匹配查询条件。
Bitmap Heap Scan：然后，数据库系统使用生成的位图来访问堆表（即实际数据表），从中提取符合条件的行。
适用范围：
范围扫描：当查询条件匹配的数据范围较大，Bitmap Heap Scan 可以更高效地处理这种情况。(比起index scan 不用遍历过去)
多条件查询：当查询涉及多个条件时，位图索引扫描可以有效地结合多个索引的结果
连接
- Join Type
内连接，左连接，右连接，全连接 - Inner Unique
内表的连接键是否有唯一约束
Nested Loop Join：嵌套循环连接，用于小数据集。
对外部表的每一行执行内表的扫描，寻找匹配的行。
Hash Join：使用哈希表来执行连接操作。
首先对一个表进行哈希，然后使用这个哈希表来查找另一个表中匹配的行。
适用于连接大表，特别是当连接键的选择性较低时。
Merge Join：先对两个表按连接键排序，然后合并匹配的行。
适用于已排序的表或可以快速排序的表。
对于连接键的选择性较高时性能较好。
其他
Hash:计算哈希值
Aggregate 执行聚合操作，例如 SUM(), COUNT(), AVG() 等。
Sort 对数据进行排序操作
Group 用于对数据进行分组，通常与聚合操作一起使用。
Limit 限制查询结果的返回行数
Materialize 用于临时存储中间结果集，以便在查询执行过程中重复使用这些结果 ,比如CTE
- Parallel Aware ：能否并行
- Parent Relationship： 和父节点的关系
- Outer：表示这个节点是作为其父节点的外部部分执行的。例如，在连接操作中，这个节点可能是外部表的扫描操作。
- Inner：表示这个节点是作为其父节点的内部部分执行的。例如，在连接操作中，这个节点可能是内表的扫描操作。
- Top：表示这是查询计划的顶层操作，通常是最终的结果集。
注意如果添加了 ANALYZE， 后面的语句会实际执行，所以如果想要不影响数据库的现有数据，需要执行
BEGIN;
EXPLAIN ANALYZE ...;
ROLLBACK;
所以实际使用的时候，并不时一定会使用索引的，比如如果只是过滤一下主键，过滤出来的数据集还是很大，那么可能用顺序扫描，如果指定主键是谁，那么会用index扫描
pgadmin里面可以直接用Explain按钮，带有图形化界面，很方便
_serial :执行顺序，越大的越先执行
statistics :有哪些节点类型，执行了多少次，参与了哪些表，表里面什么扫描，扫描了多少次
