前面已经分析了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
【编辑推荐】
