Oracle中通过位图索引提高查询效率
众所周知,索引可以在很大程度上提高数据库的查询效率。但是如果索引使用不当,如在不恰当的地方采用了不恰当的索引,那么反而会起到适得其反的效果。如下图所示的表,该采用什么索引呢?笔者借这个机会,跟大家讨论一下位图索引的使用时机以及注意事项。 一、 B树索引的缺陷。 在实际工作中,B树索引是Oracle数据库中最常用的一种索引。如在使用Create Index语句创建索引的时候,默认采用的就是B树索引。在B树索引中,是通过在索引中保存排序过的索引列以及其对应的Rowid列的值来实现的。不过对于某些比较特殊的情况,如基数比较小的
GP上的分区表
对于大数据量的表我们通常会对其按照一定规则进行分区存储,以便提高查询效率,下面简单对GP上分区表的创建、分区的增加和删除进行了整理。一、创建GP中表的分区都只能在创建表的时候定义,因此如果需要对表做分区一定要在create表的时候定义,对已经存在的表再做分区调整需要重建表并重新加载数据。单层分区表 create table h_t (a int ,b varchar(10),c date) distributed by (a) partition by list (b)(partition a values (’n',’N'),partition b values (’Y',’y'));如果在list的partition value中定义null值,在where条件中限制只
转载:解耦宽表体系
数据仓库应用中,宽表模型以结构简单,模型容易理解,数据访问效率等优势,被业界广泛采用。所谓宽表就是,基于某个实体分析对象而建立的一个逻辑数据体系,由实体的维度、描述信息、以及基于这个实体一系列度量组成。它是一个逻辑的概念,在物理实现中不可能就针对一个实体对象建立一个大宽表。因为这样,对于,刷新效率,容错能力,扩展能力都是一个很大的挑战,如何设计和组织宽表的体系结构呢?其实,我们回到软件设计的基本思想-高内聚,低耦合。我们要从在业务、ETL刷新、指标属性、数据来源等角度,让高度内聚的属性、描述、度量放
GP的规则系统
GP上的create or replace view只能重定义字段及字段类型和原视图相同的视图,如果有增加或删除字段或者字段类型发生改变此命令就无法重建视图,GP上的视图是由一种叫做规则(Rule)的机制实现的,规则用来实现一些与触发器不同的更加自定义的功能。规则系统介于查询编译器和执行优化器之间,根据规则来修改查询。GP的规则信息保存在pg_rewrite表中。基本语法:CREATE RULE 规则名 AS ON {SELECT | INSERT | UPDATE | DELETE} TO 表名 [WHERE 规则条件] DO [INSTEAD] {NOTHING | 命令 | (命令, 命令…)}建立一个视图过程如下:alig
GP优化总结
总结了一些常用的GP优化经验,分享给大家,欢迎拍砖哈!一、从技术角度1 模型优化1)分散键不合理:在初建表的时候,可能对业务理解不够或者后续需求不太明确,所建表的分散键设置不合理,导致后续使用的时候表要重分布,sql性能比较差;可以重建表来修改分散键或者使用alter table tablename set distributed by(column);语句修改分散键,如果数据量比较大的话还是重建表比较好。2)分区设置不合理:如数据量不大的表建了分区,每次使用的时候要扫描多个分区,其实每个分区的数据量不大,性能还不如不分区的好;这类情况可以将分区表改为