Greenplum乌龙事件--select count(id)不走索引

背景：

版本Greenplum Database 6.19.1

集群-两台segment服务器，2*2个segment节点，32G内存

数据是从mysq迁移到greenplum

查看表索引

select * 
from pg_indexes 
where schemaname = 'xxxx' and tablename = 'zzzz';

--关于id的索引信息--使用到的，其他未显示
CREATE UNIQUE INDEX zzzz_pkey ON xxxx.zzzz USING btree (id);

执行select count(id)查看执行计划

explain 
select count(id) from zzzz;

--执行结果如下

QUERY PLAN
Aggregate  (cost=0.00..15436.61 rows=1 width=8)
  ->  Gather Motion 4:1  (slice1; segments: 4)  (cost=0.00..15436.61 rows=1 width=8)
        ->  Aggregate  (cost=0.00..15436.61 rows=1 width=8)
              ->  Seq Scan on zzzz (cost=0.00..15085.73 rows=44482424 width=4)
Optimizer: Pivotal Optimizer (GPORCA)

发现走的是全表扫描没有走id索引列，但是根据id查询是正常走索引

explain 
select * from zzzz where id= '258061085';

--执行结果
QUERY PLAN
Gather Motion 1:1  (slice1; segments: 1)  (cost=0.00..6.00 rows=1 width=569)
  ->  Index Scan using zzzz_pkey on zzzz  (cost=0.00..6.00 rows=1 width=569)
        Index Cond: (id = 258061085)
Optimizer: Pivotal Optimizer (GPORCA)

这就奇了怪了

执行select count(id),好家伙。正常一亿多条应该在秒级别。直接12min

优化方案：

第一：执行ANALYZE

然并卵

第二：强制count(id)走索引

--会话级别关闭顺序扫描--每次会话都要设置
set enable_seqscan to off;

explain 
select count(id) from zzzz;

--结果如下

开始执行
select count(id) from zzzz;

更是好家伙 ---直奔40分钟

然并卵

第二：索引类型问题

数据是从mysql迁移到gp，导致建表sql也是按照mysql建立的，mysql中为Btree索引，在gp中可能不适用，重建索引查看性能。

--1.创建索引
CREATE UNIQUE INDEX zzzz_pkey ON xxxx.zzzz(id);
--2.查看索引类型
select * 
from pg_indexes 
where schemaname = 'xxxx' and tablename = 'zzzz';

--结果如下
CREATE UNIQUE INDEX zzzz_pkey ON xxxx.zzzz USING btree (id)

默认还是Btree索引

总结-乌龙事件

greenplum与postgres不同，postgres会走索引，但是gp不会走，并且gp不走索引会比pg快很多。