技术分享系统性能上的一根稻草：varchar的长长短短

对于繁多的数据类型，该如何取舍也是一个头疼的问题，如果用的不合适，浪费空间不说，还会在成系统性能问题，最后可能还要重构…...



作为IT人，不接触数据库是不可能的，接触数据库不接触数据存储类型也是不可能的，但是对于繁多的数据类型，该如何取舍也是一个头疼的问题，如果用的不合适，浪费空间不说，还会在成系统性能问题，最后可能还要重构。

所有数据类型中，使用比较多的就是number、char和varchar类型了。Number在oracle中比较简单;在mysql中，又分为了tinyint int mediemint bigint等，分别对应不同的存储数据范围;char是定长存储，如果实际存储不够长就以空格占位补充上;varchar是变长存储的，根据实际存储的数据来分配空间;

那么问题来了，对于varchar，既然是变长的，我们是不是可以定义的比较大?对于一个20长度左右的字符，存成Varchar（30 ) 和存成varchar（50），实际的占用存储差别不是很大，那么是不是可以直接定义的比较大，也为以后的扩展预留空间?就算以后不拓展，也没有牺牲什么?

于是做了一下实验，关于上面这个问题，差别主要体现在性能上。

1，建表：



2，造测试数据：(造的数据为随机字符串，长度在0-200之间随机生成，由于时间问题，最后只执行了部分，未全部执行完)

3，做另外一个表(区别于第一个表的是varchar的长度):4,用第一个表的数据生成第二个表的数据：

insert into t_varchar500 select * from t_varchar;

5,进行查询测试：查询两遍是为了规避第一次查询时的IO的影响;

可以看到，相同的数据，只是定义不同，执行效率也是有区别的;

继续查询是在哪一步消耗的性能：

比对profile：

可以看到最大的性能差距在构建排序上;因为这表没有索引，查询的时候用到了Using filesort。排序时，需要在内存中分配固定的空间来保存值，无形中浪费了空间，同时在排序和实用临时表的时候，有性能上的问题，如果是复杂的查询并且有表关联，那么性能上的差距会更明显的。

另外定义适度的长度以满足要求，也可以防止非法的输入，避免恶意用户的入侵。

关于varchar的长度定义，可见是不能随意定义的，满足当下需要即可，虽说现在磁盘比较便宜，但是后期的性能损耗是不可忍受的;当然对于varchar使用还有其他的限制和特性，但是本次只是测试了定义长度上的差别，关于其他的我们可以后续探讨，谢谢。

    关注 博睿数据Bonree