MySQL 中 Varchar(50) 和 varchar(500) 区别介绍

更新时间：2024年08月01日 09:29:38 作者：数据派

网上说Varchar(50)和varchar(500)存储空间上是一样的,真的是这样吗,基于性能考虑,是因为过长的字段会影响到查询性能,本文我将带着这两个问题探讨验证一下,需要的朋友可以参考下

问题

我们在设计表结构的时候，设计规范里面有一条如下规则：对于可变长度的字段，在满足条件的前提下，尽可能使用较短的变长字段长度。为什么这么规定，主要基于两个方面

基于存储空间的考虑
基于性能的考虑

网上说Varchar(50)和varchar(500)存储空间上是一样的，真的是这样吗？基于性能考虑，是因为过长的字段会影响到查询性能？
本文我将带着这两个问题探讨验证一下：

验证存储空间的区别

1、准备两张表

CREATE TABLE `category_info_varchar_50` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` varchar(50) NOT NULL COMMENT '分类名称',
  `is_show` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否展示：0 禁用，1启用',
  `sort` int(11) NOT NULL DEFAULT '0' COMMENT '序号',
  `deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `update_time` datetime NOT NULL COMMENT '更新时间',
  PRIMARY KEY (`id`) USING BTREE,
  KEY `idx_name` (`name`) USING BTREE COMMENT '名称索引'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='分类';
CREATE TABLE `category_info_varchar_500` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` varchar(500) NOT NULL COMMENT '分类名称',
  `is_show` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否展示：0 禁用，1启用',
  `sort` int(11) NOT NULL DEFAULT '0' COMMENT '序号',
  `deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `update_time` datetime NOT NULL COMMENT '更新时间',
  PRIMARY KEY (`id`) USING BTREE,
  KEY `idx_name` (`name`) USING BTREE COMMENT '名称索引'
) ENGINE=InnoDB AUTO_INCREMENT=288135 DEFAULT CHARSET=utf8mb4 COMMENT='分类';

2、准备数据

给每张表插入相同的数据，为了凸显不同，插入100万条数据

DELIMITER $$
CREATE PROCEDURE batchInsertData(IN total INT)
BEGIN
    DECLARE start_idx INT DEFAULT 1;
    DECLARE end_idx INT;
    DECLARE batch_size INT DEFAULT 500;
    DECLARE insert_values TEXT;
    SET end_idx = LEAST(total, start_idx + batch_size - 1);
    WHILE start_idx <= total DO
        SET insert_values = '';
        WHILE start_idx <= end_idx DO
            SET insert_values = CONCAT(insert_values, CONCAT('(\'name', start_idx, '\', 0, 0, 0, NOW(), NOW()),'));
            SET start_idx = start_idx + 1;
        END WHILE;
        SET insert_values = LEFT(insert_values, LENGTH(insert_values) - 1); -- Remove the trailing comma
        SET @sql = CONCAT('INSERT INTO category_info_varchar_50 (name, is_show, sort, deleted, create_time, update_time) VALUES ', insert_values, ';');
        PREPARE stmt FROM @sql;
        EXECUTE stmt;
      SET @sql = CONCAT('INSERT INTO category_info_varchar_500 (name, is_show, sort, deleted, create_time, update_time) VALUES ', insert_values, ';'); 
      PREPARE stmt FROM @sql;
        EXECUTE stmt;
        SET end_idx = LEAST(total, start_idx + batch_size - 1);
    END WHILE;
END$$
DELIMITER ;
CALL batchInsertData(1000000);

3、验证存储空间

查询第一张表SQL

SELECT
    table_schema AS "数据库",
    table_name AS "表名",
    table_rows AS "记录数",
    TRUNCATE ( data_length / 1024 / 1024, 2 )  AS "数据容量（MB）",
    TRUNCATE ( index_length / 1024 / 1024, 2 )  AS "索引容量（MB）" 
FROM
    information_schema.TABLES 
WHERE
    table_schema = 'test_mysql_field' 
and TABLE_NAME = 'category_info_varchar_50'
ORDER BY
    data_length DESC,
    index_length DESC;

查询结果

查询第二张表SQL

SELECT
    table_schema AS "数据库",
    table_name AS "表名",
    table_rows AS "记录数",
    TRUNCATE ( data_length / 1024 / 1024, 2 )  AS "数据容量（MB）",
    TRUNCATE ( index_length / 1024 / 1024, 2 )  AS "索引容量（MB）" 
FROM
    information_schema.TABLES 
WHERE
    table_schema = 'test_mysql_field' 
and TABLE_NAME = 'category_info_varchar_500'
ORDER BY
    data_length DESC,
    index_length DESC;

查询结果

4、结论

两张表在占用空间上确实是一样的，并无差别。

验证性能区别

1、验证索引覆盖查询

select name from category_info_varchar_50 where name = 'name100000'
-- 耗时0.012s
select name from category_info_varchar_500 where name = 'name100000'
-- 耗时0.012s
select name from category_info_varchar_50 order by name;
-- 耗时0.370s
select name from category_info_varchar_500 order by name;
-- 耗时0.379s

通过索引覆盖查询性能差别不大

2、验证索引查询

select * from category_info_varchar_50 where name = 'name100000'
--耗时 0.012s
select * from category_info_varchar_500 where name = 'name100000'
--耗时 0.012s
select * from category_info_varchar_50 where name in('name100','name1000','name100000','name10000','name1100000',
'name200','name2000','name200000','name20000','name2200000','name300','name3000','name300000','name30000','name3300000',
'name400','name4000','name400000','name40000','name4400000','name500','name5000','name500000','name50000','name5500000',
'name600','name6000','name600000','name60000','name6600000','name700','name7000','name700000','name70000','name7700000','name800',
'name8000','name800000','name80000','name6600000','name900','name9000','name900000','name90000','name9900000') 
-- 耗时 0.011s -0.014s 
-- 增加 order by name 耗时 0.012s - 0.015s
select * from category_info_varchar_50 where name in('name100','name1000','name100000','name10000','name1100000',
'name200','name2000','name200000','name20000','name2200000','name300','name3000','name300000','name30000','name3300000',
'name400','name4000','name400000','name40000','name4400000','name500','name5000','name500000','name50000','name5500000',
'name600','name6000','name600000','name60000','name6600000','name700','name7000','name700000','name70000','name7700000','name800',
'name8000','name800000','name80000','name6600000','name900','name9000','name900000','name90000','name9900000') 
-- 耗时  0.012s -0.014s 
-- 增加 order by name 耗时 0.014s - 0.017s

索引范围查询性能基本相同, 增加了order By后开始有一定性能差别；

3、验证全表查询和排序

全表无排序

全表有排序

select * from category_info_varchar_50 order by  name ;
--耗时 1.498s
select * from category_info_varchar_500 order by  name  ;
--耗时 4.875s

结论：

全表扫描无排序情况下,两者性能无差异,在全表有排序的情况下, 两种性能差异巨大；

分析原因

varchar50 全表执行sql分析

我发现86%的时花在数据传输上,接下来我们看状态部分,关注Created_tmp_files和sort_merge_passes

Created_tmp_files为3

sort_merge_passes为95

varchar500 全表执行sql分析

增加了临时表排序

Created_tmp_files 为 4

sort_merge_passes为645

关于sort_merge_passes, Mysql给出了如下描述：

Number of merge passes that the sort algorithm has had to do. If this value is large, you may want to increase the value of the sort_buffer_size.

其实sort_merge_passes对应的就是MySQL做归并排序的次数，也就是说，如果sort_merge_passes值比较大，说明sort_buffer和要排序的数据差距越大，我们可以通过增大sort_buffer_size或者让填入sort_buffer_size的键值对更小来缓解sort_merge_passes归并排序的次数。

最终结论

至此，我们不难发现，当我们最该字段进行排序操作的时候，Mysql会根据该字段的设计的长度进行内存预估，如果设计过大的可变长度，会导致内存预估的值超出sort_buffer_size的大小，导致mysql采用磁盘临时文件排序,最终影响查询性能。

您可能感兴趣的文章:

mysql中的int(5)到底有是多长
这篇文章主要介绍了mysql中的int(5)到底有是多长，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
2023-04-04
sql format()函数的用法及简单实例
下面小编就为大家带来一篇sql format函数()的用法及简单实例。小编觉得挺不错的，现在就分享给大家，也给大家做个参考。一起跟随小编过来看看吧
2016-05-05
MySQL InnoDB存储引擎的深入探秘
这篇文章主要给大家介绍了关于MySQL InnoDB存储引擎的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面来一起学习学习吧
2019-02-02
Mysql5.7定时备份的实现
这篇文章主要介绍了Mysql5.7定时备份的实现，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
2020-11-11
如何测试mysql触发器和存储过程
本文将详细介绍怎样mysql触发器和存储过程，需要了解的朋友可以详细参考下
2012-11-11
Mysql 5.7.18 解压版下载安装及启动mysql服务的图文详解
这篇文章主要介绍了Mysql 5.7.18 解压版下载安装及启动mysql服务的图文详解,非常不错，具有参考借鉴价值，需要的朋友可以参考下
2017-05-05
mysql5.7.42到mysql8.2.0的升级(rpm方式)
随着数据量的增长和业务需求的变更,我们可能需要升级MySQL,本文主要介绍了mysql5.7.42到mysql8.2.0的升级(rpm方式),具有一定的参考价值,感兴趣的可以了解一下
2024-03-03
mysql报错：MySQL server version for the right syntax to use nea
这篇文章主要介绍了mysql报错：MySQL server version for the right syntax to use near type=InnoDB的解决方法,涉及MySQL语句的使用技巧,需要的朋友可以参考下
2016-01-01
很全面的MySQL处理重复数据代码
这篇文章主要为大家详细介绍了MySQL处理重复数据的实现代码，如何防止数据表出现重复数据及如何删除数据表中的重复数据，感兴趣的小伙伴们可以参考一下
2016-05-05
mysql触发器实时检测一条语句进行备份删除思路详解
遇到过这样一个需求，在一张表里会不时出现 “违规” 字样的字段，需要在出现这个字段的时候，把整行的数据删掉，针对这个需求我们该如何操作呢，下面跟随小编看下mysql触发器实时检测一条语句进行备份删除的解决思路，一起看看吧
2021-09-09