VARCHAR(50) vs VARCHAR(500)：存储一样大，排序却慢了 3 倍

这是一个或许对你有用的社群 一对一交流/面试小册/简历优化/求职解惑欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料《项目实战视频》从书中学往事中“练”《互联网高频面试题》面朝简历学习春暖花开《架构 x 系统设计》摧枯拉朽掌控面试高频场景题《精进 Java 学习指南》系统学习互联网主流技术栈《必读 Java 源码专栏》知其然知其所以然这是一个或许对你有用的开源项目国产Star破10w的开源项目前端包括管理后台、微信小程序后端支持单体、微服务架构RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能多模块https://gitee.com/zhijiantianya/ruoyi-vue-pro微服务https://gitee.com/zhijiantianya/yudao-cloud视频教程https://doc.iocoder.cn【国内首批】支持 JDK17/21SpringBoot3、JDK8/11Spring Boot2双版本一个被忽视的设计规范能短就别长实验 1存储空间——确实没区别实验 2索引查询——也基本没区别实验 3全表 排序——差距 3 倍出来了真凶sort_buffer 内存预估按声明长度算决策矩阵常见字段该给多少长度4 个真实生产坑按踩到概率从高到低说到底一个被忽视的设计规范能短就别长很多团队的建表规范里都有这一条「对可变长度字段在满足业务的前提下尽可能使用较短的长度」但具体短多少为什么要短大部分人答不上来。最常见的「直觉式回答」是「VARCHAR(50)比VARCHAR(500)节省存储」—— 错。「短一点查得快」—— 对但只在特定 SQL 模式下成立。要回答清楚得做实验。下面这套实验从存储、索引查询、全表排序三个维度走一遍最后会发现90% 时间没区别但有一种 SQL 模式差距 3 倍以上——这才是规范要短的真正原因。基于 Spring Boot MyBatis Plus Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/ruoyi-vue-pro视频教程https://doc.iocoder.cn/video/实验 1存储空间——确实没区别建两张结构完全一样、只差name字段长度的表CREATE TABLE category_info_varchar_50 ( id BIGINT NOTNULL AUTO_INCREMENT, name VARCHAR(50) NOTNULL, is_show TINYINT(4) NOTNULLDEFAULT0, sort INT NOTNULLDEFAULT0, -- 其他业务字段省略 PRIMARY KEY (id), KEY idx_name (name) ) ENGINEInnoDBDEFAULTCHARSETutf8mb4; CREATETABLE category_info_varchar_500 ( id BIGINT NOTNULL AUTO_INCREMENT, name VARCHAR(500) NOTNULL, -- ... 其他字段同上 PRIMARY KEY (id), KEY idx_name (name) ) ENGINEInnoDBDEFAULTCHARSETutf8mb4;各灌 100 万条同样数据写入数据的存储过程略实际数据完全一致然后查information_schema.TABLESSELECT 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;VARCHAR(50)表VARCHAR(500)表两张表的数据容量、索引容量完全相同——VARCHAR 是变长的实际存储看的是写入内容长度不是声明的最大长度。「存储空间不一样」的直觉第一关就废。基于 Spring Cloud Alibaba Gateway Nacos RocketMQ Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/yudao-cloud视频教程https://doc.iocoder.cn/video/实验 2索引查询——也基本没区别走索引的等值查询、IN 查询、ORDER BY 索引列查询-- 等值 SELECTnameFROM category_info_varchar_50 WHEREname name100000; -- 0.012s SELECTnameFROM category_info_varchar_500 WHEREname name100000; -- 0.012s -- ORDER BY 走索引 SELECTnameFROM category_info_varchar_50 ORDERBYname; -- 0.370s SELECTnameFROM category_info_varchar_500 ORDERBYname; -- 0.379s -- IN 查询45 个值 SELECT * FROM category_info_varchar_50 WHEREnameIN (...); -- 0.011 ~ 0.014s SELECT * FROM category_info_varchar_500 WHEREnameIN (...); -- 0.012 ~ 0.014s走索引的 SQL 性能差距在 1ms 量级——可以认为没差。原因很简单InnoDB 在 DYNAMIC / COMPRESSED 行格式下索引 key 的单字段上限是 3072 字节——VARCHAR(500) utf8mb4满打满算 2000 字节完整能进索引查询走 BTree比较时按实际值长度来。索引这条路上 50 和 500 没毛病。仅在老的 REDUNDANT / COMPACT 行格式下索引 key 上限是 767 字节——这种情况下VARCHAR(500) utf8mb4才会被截断成 prefix 索引但MySQL 5.7 默认就是 DYNAMIC绝大多数项目不用担心。实验 3全表 排序——差距 3 倍出来了不走索引的全表扫描 排序差距瞬间出现无排序两张表表现一致加ORDER BY nameSELECT * FROM category_info_varchar_50 ORDER BY name; -- 1.498s SELECT * FROM category_info_varchar_500 ORDER BY name; -- 4.875sVARCHAR(50) 全表排序耗时VARCHAR(500) 全表排序耗时VARCHAR(500)慢了 3.25 倍。一个看着无所谓的字段长度选择在排序场景下变成了真问题。真凶sort_buffer 内存预估按声明长度算为什么会差这么多看 SQL 执行 profile。VARCHAR(50)的 profile——86% 时间在数据传输Sending data关注两个状态变量Created_tmp_files和sort_merge_passesCreated_tmp_files 3sort_merge_passes 95VARCHAR(500)的 profile——多了「临时表排序」环节Created_tmp_files 4sort_merge_passes 645—— 比 50 的版本暴涨 6.8 倍sort_merge_passes是 MySQL 归并排序的次数——越大说明sort_buffer塞不下越要靠磁盘临时文件归并磁盘 IO 上来性能就崩。关键来了MySQL 在做排序前会根据字段声明的最大长度估算每条记录在sort_buffer里的占位——VARCHAR(500)单条估到 500 字节 元数据开销VARCHAR(50)估到 50 字节。同样 8MB 的sort_buffer_size字段长度估算单条装得下行数100 万行需要归并次数VARCHAR(50)~58 字节~144,000~7 轮VARCHAR(500)~558 字节~15,000~67 轮实际数据明明都是name123456这种十几字节的字符串但 MySQL 不看这个——它只看声明长度。这就是规范让你「能短就短」的真正动机在排序、分组、临时表场景下声明长度直接决定内存利用率。决策矩阵常见字段该给多少长度不是越短越好太短了改起来更痛苦。给个参考字段类型推荐长度理由用户名 / 昵称VARCHAR(64)主流业务 32-50 够用留点余量邮箱VARCHAR(128)RFC 5321 上限 254但实际 128手机号CHAR(20)定长且固定CHAR 比 VARCHAR 更适合URLVARCHAR(512)或VARCHAR(1024)长 URL 现实存在但避免 VARCHAR(2000)标题 / 名称VARCHAR(128)业务分类、文章标题、商品名都够描述 / 富文本TEXT一旦超过 1KB 用 TEXT别拿 VARCHAR(8000) 死撑UUID / 雪花 IDCHAR(36)/BIGINT定长用 CHAR雪花用 BIGINT极不确定的开放字段JSON或拆出独立表别用 VARCHAR(N) 当万能桶为什么不无脑用 VARCHAR(255)历史遗留——MySQL 5.0.3 之前 VARCHAR 上限是 255 字节模板默认 255。现在 InnoDB 上 VARCHAR 最长 65535 字节但越长在排序场景代价越大。4 个真实生产坑按踩到概率从高到低坑 1分页查询带排序TP99 突然劣化最常见ORDER BY name LIMIT 100, 10看起来很轻——前端列表分页谁不写但只要 ORDER BY 字段没走索引、且字段是 VARCHAR(500)sort_buffer 直接爆。监控里 TP99 飙升、慢查询日志炸出一堆Using filesort; Using temporary。修法要么给 ORDER BY 字段加索引要么把字段长度收紧要么调大sort_buffer_size但调大全实例都受影响要慎重。坑 2临时表 GROUP BY 拼字段常见SELECT category, COUNT(*) FROM ... GROUP BY category;GROUP BY 也走 sort_buffer 或临时表逻辑同 ORDER BY。长 VARCHAR 字段做 GROUP BY 同样吃亏。坑 3UNION 把多张表的字段长度并起来少见但破坏力大SELECT name FROM table_a -- VARCHAR(50) UNION SELECT name FROM table_b; -- VARCHAR(500)UNION 结果集字段长度按最大的那个算——本来 50 就够UNION 一接结果集里全按 500 估。复杂报表 SQL 把多个表的字段拼起来性能突然崩就是这种问题。坑 4JSON字段当 VARCHAR 用高级场景「业务字段不确定先放 JSON」——三年后字段平均 5KB涉及它的查询、排序、临时表全炸。JSON 比 VARCHAR(N) 对 sort_buffer 更不友好。该拆表必须拆别拿 JSON 顶。说到底VARCHAR(50)和VARCHAR(500)在存储、走索引的查询上没区别——这条规范的真正意义在 sort_buffer 上。好的字段长度设计不是「能存就行」是「让 MySQL 在排序时不被声明长度欺骗到磁盘上」。欢迎加入我的知识星球全面提升技术能力。 加入方式“长按”或“扫描”下方二维码噢星球的内容包括项目实战、面试招聘、源码解析、学习路线。文章有帮助的话在看转发吧。 谢谢支持哟 (*^__^*