MySQL中int、char、varchar的性能浅谈

网络上有许多似是而非的“谣言”,固然都不是恶意,绝大部分都是开发者不肯意本身主动研究,反而轻信其余人的信口之言。数据库

关于数据库的谣言也有很多,好比“int性能比char高不少”。网络

我最近针对int、long、char、varchar进行了一次性能测试,发现它们其实并无太大的性能差距:性能

备注:c8=char(8), s8=varchar(8), i8=(bigint), c4=char(4), s4=varchar(4), i4=char(4)测试

100w行无索引状况下查询:
执行[c8查询]20次, 平均耗时312.0ms
执行[s8查询]20次, 平均耗时334.3ms
执行[i8查询]20次, 平均耗时276.95ms
执行[c4查询]20次, 平均耗时354.95ms
执行[s4查询]20次, 平均耗时340.45ms
执行[i4查询]20次, 平均耗时291.1ms索引

建立索引:
c8索引耗时2439ms
s8索引耗时2442ms
i8索引耗时1645ms
c4索引耗时2296ms
s4索引耗时2303ms
i4索引耗时1403ms开发

有索引状况下查询:
执行[c8查询]10000次, 平均耗时0.271ms
执行[s8查询]10000次, 平均耗时0.2354ms
执行[i8查询]10000次, 平均耗时0.2189ms
执行[c4查询]10000次, 平均耗时0.303ms
执行[s4查询]10000次, 平均耗时0.3094ms
执行[i4查询]10000次, 平均耗时0.25ms字符串

结论:
无索引:全表扫描不会由于数据较小就变快,而是总体速度相同,int/bigint做为原生类型稍快12%。
有索引:char与varchar性能差很少,int速度稍快18%扩展

在数据存储、读写方面,整数与等长字符串相同,varchar额外多了一个字节因此性能可能会些许影响(1/n)。
在数据运算、对比方面,整数得益于原生支持,所以会比字符串稍快一丁点
若采用索引,所谓整数、字符串的性能差距更是微乎其微。数据类型

在实际开发中,许多开发者常常使用char(1)、char(4)这样的字符串表示类型枚举,这种作法在我看来属于最佳方案,由于这种作法在存储空间、运算性能、可读性、可维护性、可扩展性方面,远胜于int、enum这种数据类型。数据

相关文章
相关标签/搜索