开发者社区> 问答> 正文

对所有基于文本的字段使用通用varchar(255)有不利之处吗??mysql

我有一个contacts包含字段,如表postcode,first name,last name,town,country,phone number等等,所有这些都被定义为VARCHAR(255)即使没有这些领域都不会接近有255个字符。(如果您想知道,那就是这种方式,因为Ruby on Rails迁移VARCHAR(255)默认将String字段映射到String字段,而我从不费心重写它)。

由于VARCHAR将仅存储字段的实际字符数(以及字段长度),因此,使用VARCHAR(16)over 相比有什么明显的优势(性能或其他方面)VARCHAR(255)?

此外,这些字段中的大多数都有索引。字段上较大的VARCHAR大小是否会完全影响索引的大小或性能?

仅供参考,我正在使用MySQL 5。

展开
收起
保持可爱mmm 2020-05-17 11:19:02 580 0
1 条回答
写回答
取消 提交回答
  • 在存储中,VARCHAR(255)它足够聪明,可以仅存储给定行上所需的长度,而CHAR(255)后者通常会存储255个字符。

    但是,由于您使用MySQL标记了此问题,因此我将提到一个MySQL特定的技巧:将行从存储引擎层复制到SQL层时,VARCHAR将转换字段CHAR以获得利用固定宽度行的优势。因此,内存中的字符串将填充到声明的VARCHAR列的最大长度。

    当查询隐式生成临时表时(例如在排序或时)GROUP BY,这会占用大量内存。如果您使用很多VARCHAR(255)字段来存储不需要那么长的数据,这会使临时表变得非常大。

    您可能还想知道,这种“填充”行为意味着,即使您存储的是单字节内容的字符串(例如ascii或latin1字符),用utf8字符集声明的字符串也每个字符填充至三个字节。同样,utf8mb4字符集会使字符串在内存中每个字符填充到四个字节。

    因此,VARCHAR(255)在utf8中,存储诸如“无意见”之类的短字符串的磁盘上需要11个字节(十个低字符集字符,再加上一个字节的长度),但是在内存中则需要765个字节,因此在临时表或排序结果中也是如此。

    我曾帮助不知不觉地频繁创建1.5GB临时表并填满磁盘空间的MySQL用户。他们有很多VARCHAR(255)列,实际上存储很短的字符串。

    最好根据要存储的数据类型定义列。如其他人所提到的,它具有强制执行与应用程序相关的约束的好处。但是它具有避免上面所述的内存浪费的物理好处。

    当然,很难知道最长的邮政地址是什么,这就是为什么许多人选择的长度VARCHAR肯定比任何地址都要长的原因。通常使用255,因为它是a的最大长度VARCHAR,该长度可以用一个字节编码。它也是VARCHARMySQL早于5.0 的最大长度。来源:stack overflow

    2020-05-17 11:31:52
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
One Box: 解读事务与分析一体化数据库 HybridDB for MySQL 立即下载
One Box:解读事务与分析一体化数据库HybridDB for MySQL 立即下载
如何支撑HTAP场景-HybridDB for MySQL系统架构和技术演进 立即下载

相关镜像