(转载)对比MySQL中int、char 以及 varchar 的性能

转载:https://www.jb51.net/article/148819.htm

网络上有许多似是而非的“谣言”,当然都不是恶意,绝大部分都是开发者不愿意自己主动研究,反而轻信其他人的信口之言。

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

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

备注:
c8=char(8), v8=varchar(8), i8=(bigint),
c4=char(4), v4=varchar(4), i4=char(4)

100w行 无索引情况下查询:

执行[c8查询]20次, 平均耗时312.0ms 
执行[v8查询]20次, 平均耗时334.3ms 
执行[i8查询]20次, 平均耗时276.95ms 

执行[c4查询]20次, 平均耗时354.95ms 
执行[v4查询]20次, 平均耗时340.45ms 
执行[i4查询]20次, 平均耗时291.1ms

创建索引:

c8索引耗时2439ms 
v8索引耗时2442ms 
i8索引耗时1645ms 

c4索引耗时2296ms 
v4索引耗时2303ms 
i4索引耗时1403ms

有索引情况下查询:

执行[c8查询]10000次, 平均耗时0.271ms 
执行[v8查询]10000次, 平均耗时0.2354ms 
执行[i8查询]10000次, 平均耗时0.2189ms 

执行[c4查询]10000次, 平均耗时0.303ms 
执行[v4查询]10000次, 平均耗时0.3094ms 
执行[i4查询]10000次, 平均耗时0.25ms

结论:
无索引: 全表扫描不会因为数据较小就变快,而是整体速度相同,int/bigint作为原生类型稍快12%。
有索引: char与varchar性能差不多,int速度稍快18%

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

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

猜你喜欢

转载自blog.csdn.net/xiaojin21cen/article/details/83653182