注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

zjcjack的博客

 
 
 

日志

 
 

infobright的bigint型与varchar型效率对比  

2012-04-04 22:15:56|  分类: infobright |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

一直以来的感觉都是在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了。

  评论这张
 
阅读(304)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017