infobright數據倉庫能在高強度的壓縮中把大量的數據壓縮存儲，平時在不斷查詢的過程就是在做數據解壓的過程，當然具體的詳細介紹在以前有提過，這裏就不做過程的介紹（http://blog.51cto.com/jim123/1975029）在infobright中支持所有的MySQL原有的數據類型，其中對整形的效率會比其他類型高，這一點同MySQL差不多，在infobright中比較高效的類型如下：
1、TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT
2、DECIMAL（儘量減少小數點後的精度）
3、DATE ，TIME
這3種類型的數據能有比較高的壓縮比例及查詢速度，而效率比較低的、不推薦使用的數據類型有這幾種：
1、BINARY VARBINARY（二進制類型）
2、FLOAT
3、DOUBLE
4、VARCHAR
5、TINYTEXT TEXT（可變長度的非Unicode類型）
這些數據類型在使用的過程中效率比較低且壓縮比例並不是很高，其中VARCHAR字段在MySQL中效率就不如CHAR字段，當然在某些業務場景下可能會不得不用到CHAR（VARCHAR）的時候又經常需要頻繁的查詢時，但數據的記錄數又並不是很多時（不多於10000行，且數據的類型多於10種以上，類似於省份、UUID這類的數據），就可以通過comment lookup的方式創建建表時的DDL來提高平時查詢的效率如下：
#原建表DDL CREATE TABLE `test_default` ( `dstphone` varchar(11) DEFAULT NULL, `gateid` varchar(255) DEFAULT NULL ) ENGINE=BRIGHTHOUSE DEFAULT CHARSET=utf8; #comment lookup建表DDL CREATE TABLE `test_lookup` ( `dstphone` varchar(11) DEFAULT NULL COMMENT 'lookup', `gateid` varchar(255) DEFAULT NULL COMMENT 'lookup' ) ENGINE=BRIGHTHOUSE DEFAULT CHARSET=utf8;
這裏需要注意的是comment lookup的方式目前僅有在CHAR（VARCHAR）中能使用，其次在平時帶來更高的查詢效率所帶來的代價就是磁盤開銷，因爲infobright在平時查詢的時候就是在做解壓的過程，所以使用comment lookup的方式就是降低壓縮比例，在查詢的時候能更快速的解壓數據，如下可以看出comment lookup的方式同默認的建表時不同的壓縮比例
查詢效率如下：
可以看相同的數據下所佔用磁盤空間，但相應的在查詢記錄不能超過10000行，不然反而還會降低其效率：
所以在使用的過程中還需要根據實際情況來選擇