背景:
版本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快很多。