解释命令是解决数据库性能的第一个推荐命令，大部分性能问题都可以通过这个命令简单解决。解释可以用来检查SQL语句的执行效果，可以帮助选择更好的索引，优化查询语句，写出更好的优化语句。

解释语法：

1解释选择…从…[哪里.]

例如：

1解释选择*从dual

下面是一个简单的例子：

EX唐山seo公司PLAIN SELECT * FROM tenk1

查询计划

-

tenk1上的序列扫描(成本=0.00.458.00行=10000宽=244)

解释参考数据是：

1).预计启动成本(开始输出扫描之前消耗的时间，如排序节点中的调度时间)。

2).估计总成本。

3).计划节点输出的估计行数。

4).计划节点的估计平均行宽度(单位：字节)。

这里，成本的计算单位是磁盘页面的访问次数。例如，1.0将意味着顺序磁盘页面读取。其中上层节点的开销将包括其所有子节点的开销。这里输出的行数并不是规划节点处理/扫描的行数，通常更少。一般来说，顶层的预期行数更接近查询实际返回的行数。

现在，我们基于系统表执行以下查询：

1SELECT relpages，rel元组FROM pg _ class WHERE rel name=' ten k1 '；

从查询结果可以看出，tenk1表占用了358个磁盘页，10000条记录，但是为了计算成本值，我们还需要知道另一个系统参数值。

postgres=# show cpu _ tuple _ cost

cpu _元组_成本

-

0.01

(1行)

成本=458(磁盘页数)10000(行数)* 0.01(cpu_tuple_cost系统参数值

补充：PostgreSQL SQL计数(distnct字段)优化

背景

统计某段时间内所有关键字的总数也包括null(统计有400w数据，表大小为600M)，所以

编写sql:

1从统计数据中选择count(distinct关键字)1作为计数；

问题

虽然是后台查询，但是太慢，执行时间38.6s，如何优化？

解决

方法1(治疗症状)

定期执行它，然后缓存sql结果，然后程序访问缓存的结果。页面访问更快，但是sql执行速度慢的问题并没有得到本质上的解决。

方法2(根本原因)

为了优化sql，让我们先来谈谈为什么count(distinct FIELD)这么慢。这里就不赘述了。请看这个：https://www.jb51.net/article/65680.htm

优化内容：

1从表中选择计数(非重复字段)

修改为

1从(从表中选择不同的字段)中选择计数(1)作为foo

比较

执行进程比较，可以使用explian anaylze sql语句查看