说米网

Explain指令在处理数据库性能上是第一引荐运用指令，大部分的性能问题能够经过此指令来简略的处理，Explain能够用来检查 SQL 句子的履行效 果，能够协助挑选更好的索引和优化查询句子，写出更好的优化句子。

Explain语法：

1explain select … from … [where …]

例如：

1explain select * from dual;

这儿有一个简略的例子，如下：

EXPLAIN SELECT * FROM tenk1;
QUERY PLAN
—————————————————————-
Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)

EXPLAIN引用的数据是：

1). 估计的发动开支(在输出扫描开始之前耗费的时刻，比如在一个排序节点里做排续的时刻)。

2). 估计的总开支。

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

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

这儿开支(cost)的核算单位是磁盘页面的存取数量，如1.0将表明一次顺序的磁盘页面读取。其中上层节点的开支将包括其一切子节点的开支。这儿的输出行数(rows)并不是规划节点处理/扫描的行数，通常会更少一些。一般而言，顶层的行估计数量会更接近于查询实践回来的行数。

现在咱们履行下面基于体系表的服务器管理软件查询：

1SELECT relpages, reltuples FROM pg_class WHERE relname = ‘tenk1’;

从查询成果中能够看出tenk1表占有358个磁盘页面和10000条记载，可是为了核算cost的值，咱们仍然需要知道别的一个体系参数值。

postgres=# show cpu_tuple_cost;
cpu_tuple_cost
—————-
0.01
(1 row)
cost = 458(磁盘页面数) + 10000(行数) * 0.01(cpu_tuple_cost体系参数值

补充：postgresql SQL COUNT(DISTNCT FIELD) 优化

布景

统计某时段关键词的一切总数，也包含null （statistics 有400w+的数据，表大小为 600M），故

写出sql：

1select count(distinct keyword) +1 as count from statistics;

问题

虽然是后台查询，可是太慢了，履行时刻为为 38.6s，那怎么优化呢？

处理

办法1（治标）

把这个定时履行，然后把sql成果缓存下，然后程序拜访缓存成果，页面拜访是快了些，可是本质上还没有处理sql履行慢的问题。

办法2（治本）

优化sql，首先说说 count( distinct FIELD) 为啥这么慢，此处不再赘述了，请看这篇：https://www.jb51.net/article/65680.htm

优化内容：

1select count( distinct FIELD ) from table

修改为

1select count(1) from (select distinct FIELD from table) as foo;

比较

履行过程比对，能够运用 explian anaylze sql句子 检查