infobright 的bigint型与varchar型效率对比

小编辑 发布于 2010/02/03 06:07
阅读 1K+
收藏 1

一直以来的感觉都是在infobright里存储BIGINT会比存储VARCHAR要好,这两天做了个实验验证了这点。

试验环境:gentoo, ICE3.2

试验前提:

建立了两个库db1和db2,两个库内有一个同名表testlog,两个表存储的数据类型除了BID一个字段之外其余都是 一样的。db1的BID字段是BIGINT型,db2的BID字段是VARCHAR(12)型。BID字段实际是一段cookie,原本是字符串类型的, 在python里通过

struct.unpack(’Q', base64.b64decode(bid[:12])[0])

把它转换为BIGINT型。

说明:

在mysql里,INT占用4个字节,BIGINT占用8个字节,VARCHAR(12)占用12个字节。

测试查询涉及的总记录条数:414360862

查询语句:select distinct uid from weblog where date between ‘xxxx’ and ‘xxxx’ and bid=”xxxxxxx”。bid条件根据类型为BIGINT或VARCHAR而不同。

衡量指标:查询效率、查询时载入数据量、占用硬盘空间量(因为db1和db2总数据量有差异,这个指标以BID/另一个INT字段容量的比率来衡 量)。

ICE配置:db1和db2两个服务的配置都是一样的,ServerMainHeapSize=10000M

BIGINT:

查询后载入数据占内存空间4112M, 查询效率:126 rows in set (2 min 32.17 sec)

相对另一INT字段的空间占用量比率:1.43

VARCHAR(12):

查询后载入数据占内存空间7266M,查询效率:126 rows in set (9 min 18.84 sec)

相对另一INT字段的空间占用量比率:2.04

结论:能用INT/BIGINT的就用它们吧,减少varchar或text了。

加载中
0
李剑
李剑

看来以后要注意了.我从来没想过这样的事情.更不好说去测试了...唉...

返回顶部
顶部