前面已经分析了Infobright的构架，简要介绍了Infobright的压缩过程和工作原理。现在来讨论查询优化的问题。

（1）配置环境

在Linux下面，Infobright环境的配置可以根据README里的要求，配置brighthouse.ini文件。

（2） 选取高效的数据类型

参见《细数Infobright的相关数据类型》。

（3）使用comment lookup

comment lookup只能显式地使用在char或者varchar上面。Comment Lookup可以减少存储空间，提高压缩率，对char和varchar字段采用comment lookup可以提高查询效率。

Comment Lookup实现机制很像位图索引，实现上利用简短的数值类型替代char字段已取得更好的查询性能和压缩比率。CommentLookup的使用除了对数据类型有要求，对数据也有一定的要求。一般要求数据类别的总数小于10000并且当前列的单元数量/类别数量大于10。Comment Lookup比较适合年龄，性别，省份这一类型的字段。

comment lookup使用很简单，在创建数据库表的时候如下定义即可：

act   char(15)   comment 'lookup',

part  char(4) comment 'lookup',

（4）尽量有序地导入数据

前面分析过Infobright的构架，每一列分成n个DP，每个DPN列面存储着DP的一些统计信息。有序地导入数据能够使不同的DP的DPN内的数据差异化更明显。比如按时间date顺序导入数据，那么前一个DP的max（date）<=下一个DP的min(date)，查询的时候就能够减少可疑DP，提高查询性能。换句话说，有序地导入数据就是使DP内部数据更加集中，而不再那么分散。

（5）使用高效的查询语句。

这里涉及的内容比较多了，总结如下：

尽量不适用or，可以采用in或者union取而代之

减少IO操作，原因是infobright里面数据是压缩的，解压缩的过程要消耗很多的时间。

查询的时候尽量条件选择差异化更明显的语句

Select中尽量使用where中出现的字段。原因是Infobright按照列处理的，每一列都是单独处理的。所以避免使用where中未出现的字段可以得到较好的性能。

限制在结果中的表的数量，也就是限制select中出现表的数量。

尽量使用独立的子查询和join操作代替非独立的子查询

尽量不在where里面使用MySQL函数和类型转换符

尽量避免会使用MySQL优化器的查询操作

使用跨越Infobright表和MySQL表的查询操作

尽量不在group by 里或者子查询里面使用数学操作，如sum（a*b）。

select里面尽量剔除不要的字段。

Infobright执行查询语句的时候，大部分的时间都是花在优化阶段。Infobright优化器虽然已经很强大，但是编写查询语句的时候很多的细节问题还是需要程序员注意。　

原文链接：http://blog.chinaunix.net/u2/72637/showart_2306114.html

【编辑推荐】

1. 走进列数据库Infobright的世界
2. Infobright列数据库的构架分析
3. 51CTO专访盖国强：NoSQL很火 但还需市场检验
4. 详解NoSQL数据库使用实例
5. 云计算时代NoSQL当道 关系数据库日薄西山