PostgreSQL中的执行计划

EXPLAN

预生成执行计划

EXPLAN sql

真实执行计划

explan analyze sql

输出详细内容

explan(analyze on, timing on,verbose on,buffers on,costs on) sql

语法

EXPLAIN [ ( option [, ...] ) ] statement EXPLAIN [ ANALYZE ] [ VERBOSE ] statemen

选项：

• analyze：执行语句并显示真正的运行时间和其他统计信息，会真正的执行SQL语句
• verbose：显示额外的信息，尤其是计划树中每个节点的字段列表，schema识别表和函数名称。总是打印统计数据中每个触发器的名字
• costs：包括每个计划节点的启动成本预估和总成本的消耗，也包括行数和行宽度的预估
• buffers：使用信息，特别包括共享块命中、读、脏和写的次数。本地块命中、读、脏和写，临时块读和写的次数。
• timing：在输出中包含实际启动时间和每个节点花费的时间，重复读系统块在某些系统上会显著的减缓查询的速度，只在analyze也启用的时候使用
• format：声明输出格式，可以为text、xml、JSON或YAML，默认text

EXPLAN输出

• cost：第一个数字表示启动的成本，也就是返回第一行需要多少cost值，第二个数字表示返回所有数据的cost。默认cost值如下：

  顺序扫描一个数据块，cost值定位1，参数为sql_page_cost

  随机扫描一个数据块，cost值定为4，参数为random_page_cost

  处理一个数据行的CPU，cost为0.01，参数为cpu_tuple_cost

  处理一个索引行的CPU，cost为0.005，参数为cpu_index_tuple_cost

  每个操作符的CPU代价为0.0025，参数为cpu_operator_cost

• rows：表示会返回多少行

• width：表示每行平均宽度为多少字节

• buffers

  shared hit：表示在共享内存中直接读到XXX个块

  read：表示从磁盘读了XXX块

  written：写磁盘XXX块

执行计划的含义

• Seq Scan：全表扫描

• Index Scan：索引扫描

• Bitmap Heap Scan：位图扫描

• Filter：条件过滤

• Nestloop Join：嵌套循环连接，是在两个表做连接时，内表被外表驱动，外表返回的每一行都要在内表中检索找到与它匹配的行，因此整个查询返回的结果集不能太大，要把返回结果集较小的表作为外表，而且在内表的连接字段上要有索引，否则会很慢。

• Hash Join：使用两个表中较小的表，并利用连接键在内存中建立散列表，然后扫描较大的表并探测散列表，找出与散列表匹配的行。适用于较小的表可以完全放入内存中的情况。

• Merge Join：如果源数据上有索引，或者结果已经被排序。在执行排序合并连接时就不需要排序了。

标签：返回,执行,PostgreSQL,扫描,计划,sql,analyze,cost
来源： https://blog.csdn.net/weixin_49756466/article/details/122116876