MySQL中 int、char 以及 varchar 的性能对比

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

一、背景

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

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

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

二、测试

2.1、准备

char8 = char(8) 、 varchar8 = varchar(8) 、 bigint8 = bigint(8)
char4 = char(4) 、 varchar4 = varchar(4) 、 bigint4 = bigint(4)

执行引擎为InnoDB， 数据是100w 条。

2.2、无索引情况下查询

执行[char8 查询] 20次, 平均耗时312.0ms 
执行[varchar8 查询] 20次, 平均耗时334.3ms 
执行[bigint8 查询] 20次, 平均耗时276.95ms 

执行[char4 查询] 20次, 平均耗时354.95ms 
执行[varchar4 查询] 20次, 平均耗时340.45ms 
执行[bigint4 查询] 20次, 平均耗时291.1ms

2.3、创建索引的耗时

char8 索引耗时2439ms  
varchar8 索引耗时2442ms 
bigint8 索引耗时1645ms 

char4 索引耗时2296ms 
varchar4 索引耗时2303ms 
bigint4 索引耗时1403ms

2.4、有索引情况下查询：

执行[char8 查询] 10000次, 平均耗时0.271ms 
执行[varchar8 查询] 10000次, 平均耗时0.2354ms 
执行[bigint8 查询] 10000次, 平均耗时0.2189ms 

执行[char4 查询] 10000次, 平均耗时0.303ms 
执行[varchar4 查询] 10000次, 平均耗时0.3094ms 
执行[bigint4 查询] 10000次, 平均耗时0.25ms

三、结论

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

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

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