mysql-greenplum常见的问题以及优化

尽量不要使用limit,gp会进行全盘扫描来。
上图mysql修改成一下greenplum

---

子查询较多的可以进行拆分来减少执行时间。

不用经常修改的表，经常被引用到就用 列存
一定要指定分布策略,不过对业务不是很理解的话就要随机分布，如果对业务理解,保证数据分布后没有造成数据倾斜,就指定列分布

建表时可使用分布策略。hash分布(DISTRIBUTED BY)和随机分布(DISTRIBUTED RANDOMLY)两种分布策略，只适合存放经过处理基本最终无变化的历史数据，用来提供高效的查询访问。（使用表关系较强的不建议使用）。

解析说明：appendonly=true （）,compresslevel=5，orientation=COLUMN
在greenplum里面有一种appendonly表，只能insert，不能update、delete的一种表，对于压缩表跟列存储来说，前提是必须是appendonly的表
Compresslevel 表示压缩等级 orientation=COLUMN 方向为列存

例：(appendonly=true,orientation=COLUMN,compresstype=zlib,compresslevel=5);
1.COMPRESSTYPE：ZLIB(更高压缩率)、QUICKLZ(更快压缩)、RLE_TYPE(运行长度编码)、none(无压缩、缺省)
2.COMPRESSLEVEL：ZLIB为1-9级可选，1级最低，9级最高；QUICKLZ仅1级压缩可选；RLE_TYPE为1-4级可选，1级快但压缩率低，4级较慢但压缩率高
3.BLOCKSIZE：8K~2M

如创建临时表是可以使用：

建表详细这里引用一位大哥的播客：http://blog.itpub.net/25548387/viewspace-690470/

使用强转会损耗时间。（可以优化）

select  gp_segment_id,count(1)  from  cm_facility 
GROUP BY  1
ORDER BY  1

可以以上语句来查询分布列的倾斜率

对于存在子查询的update语句可以。创建零时表然后再拆分插入。