首页 > 语言 > 关键词  > MySQL数据库最新资讯  > 正文

MySQL数据库中CHAR与VARCHAR之争

2011-05-03 16:45 · 稿源:IT168

在数据库中,字符型的数据是最多的,可以占到整个数据库的80%以上。为此正确处理字符型的数据,对于提高数据库的性能有很大的作用。在字符型数据中,用的最多的就是Char与Varchar两种类型。前面的是固定长度,而后面的是可变长度。现在我们需要考虑的是,在什么情况下使用Char字符型数据,什么情况下采用Varchar字符型数据。在这部分内容中,我就跟大家来探讨一下这个话题。

一、VARCHAR与CHAR字符型数据的差异

在MySQL数据库中,用的最多的字符型数据类型就是Varchar和Char.。这两种数据类型虽然都是用来存放字符型数据,但是无论从结构还是从数据的保存方式来看,两者相差很大。而且其具体的实现方式,还依赖与存储引擎。我这里就以大家最常用的MYISAM存储引擎为例,谈谈这两种数据类型的差异。在后续建议中,也是针对这种存储类型而言的。

这里首先需要明白的一点是,这两种数据类型,无论采用哪一种存储引起,系统存储数据的方式都是不同的。正是因为如此,我们才有必要研究两者的不同。然后在合适的情况下,采用恰当的方式。了解这一点之后,我们再来看后续的内容。

Varchar往往用来保存可变长度的字符串。简单的说,我们只是给其固定了一个最大值,然后系统会根据实际存储的数据量来分配合适的存储空间。为此相比CHAR字符数据而言,其能够比固定长度类型占用更少的存储空间。不过在实际工作中,由于某系特殊的原因,会在这里设置例外。如管理员可以根据需要指定ROW_FORMAT=FIXED选项。利用这个选项来创建MyISAM表的话,系统将会为每一行使用固定长度的空间。此时会造成存储空间的损耗。通常情况下,VARCHAR数据类型能够节约磁盘空间,为此往往认为其能够提升数据库的性能。不过这里需要注意的是,这往往是一把双刃剑。其在提升性能的同时,往往也会产生一些副作用。如因为其长度是可变的,为此在数据进行更新时可能会导致一些额外的工作。如在更改前,其字符长度是10位(Varchar规定的最长字符数假设是50位),此时系统就只给其分配10个存储的位置(假设不考虑系统自身的开销)。更改后,其数据量达到了20位。由于没有超过最大50位的限制,为此数据库还是允许其存储的。只是其原先的存储位置已经无法满足其存储的需求。此时系统就需要进行额外的操作。如根据存储引擎不同,有的会采用拆分机制,而有的则会采用分页机制。

CHAR数据类型与VARCHAR数据类型不同,其采用的是固定长度的存储方式。简单的说,就是系统总为其分配最大的存储空间。当数据保存时,即使其没有达到最大的长度,系统也会为其分配这么多的存储空间。显然,这种存储方式会造成磁盘空间的浪费。这里笔者需要提醒的一点是,当字符位数不足时,系统并不会采用空格来填充。相反,如果在保存CHAR值的时候,如果其后面有空值,系统还会自动过滤其空格。而在进行数据比较时,系统又会将空格填充到字符串的末尾。

显然,VARCHAR与CHAR两种字符型数据类型相比,最大的差异就是前者是可变长度,而后者则是固定长度。在存储时,前者会根据实际存储的数据来分配最终的存储空间。而后者则不管实际存储数据的长度,都是根据CHAR规定的长度来分配存储空间。这是否意味着CHAR的数据类型劣于VARCHAR呢?其实不然。否则的话,就没有必要存在CHAR字符类型了。虽然VARCHAR数据类型可以节省存储空间,提高数据处理的效率。但是其可变长度带来的一些负面效应,有时候会抵消其带来的优势。为此在某些情况下,还是需要使用Char数据类型。

二、项目建议

根据上面的分析,我们知道VARCHAR数据类型是一把双刃剑,其在带来性能提升的同时,也可能会存在着一些额外的消耗。我们在评估到底是使用VARCHAR数据类型还是采用CHAR数据类型时,就需要进行均衡。在实际项目中,我们会考量如下情况。

一是根据字符的长度来判断。如某个字段,像人的名字,其最长的长度也是有限的。如我们给其分配18个字符长度即可。此时虽然每个人的名字长度有可能不同,但是即使为其分配了固定长度的字符类型,即18个字符长度,最后浪费的空间也不是很大。而如果采用NVARCHAR数据类型时,万一以后需要改名,而原先的存储空间不足用来容纳新的值,反而会造成一些额外的工作。在这种情况下,进行均衡时,会认为采用CHAR固定长度的数据类型更好。在实际项目中,如果某个字段的字符长度比较短此时一般是采用固定字符长度。

二是考虑其长度的是否相近。如果某个字段其长度虽然比较长,但是其长度总是近似的,如一般在90个到100个字符之间,甚至是相同的长度。此时比较适合采用CHAR字符类型。比较典型的应用就是MD5哈希值。当利用MD5哈希值来存储用户密码时,就非常使用采用CHAR字符类型。因为其长度是相同的。另外,像用来存储用户的身份证号码等等,一般也建议使用CHAR类型的数据。

另外请大家考虑一个问题,CHAR(1)与VARCHAR(1)两这个定义,会有什么区别呢?虽然这两个都只能够用来保存单个的字符,但是VARCHAR要比CHAR多占用一个存储位置。这主要是因为使用VARCHAR数据类型时,会多用1个字节用来存储长度信息。这个管理上的开销CHAR字符类型是没有的。

三是从碎片角度进行考虑。使用CHAR字符型时,由于存储空间都是一次性分配的。为此某个字段的内容,其都是存储在一起的。单从这个角度来讲,其不存在碎片的困扰。而可变长度的字符数据类型,其存储的长度是可变的。当其更改前后数据长度不一致时,就不可避免的会出现碎片的问题。故使用可变长度的字符型数据时,数据库管理员要时不时的对碎片进行整理。如执行数据库导出导入作业,来消除碎片。

四是即使使用Varchar数据类型,也不能够太过于慷慨。这是什么意思呢?如现在用户需要存储一个地址信息。根据评估,只要使用100个字符就可以了。但是有些数据库管理员会认为,反正Varchar数据类型是根据实际的需要来分配长度的。还不如给其大一点的呢。为此他们可能会为这个字段一次性分配200个字符的存储空间。这VARCHAR(100)与VARCHAR(200)真的相同吗?结果是否定的。虽然他们用来存储90个字符的数据,其存储空间相同。但是对于内存的消耗是不同的。对于VARCHAR数据类型来说,硬盘上的存储空间虽然都是根据实际字符长度来分配存储空间的,但是对于内存来说,则不是。其时使用固定大小的内存块来保存值。简单的说,就是使用字符类型中定义的长度,即200个字符空间。显然,这对于排序或者临时表(这些内容都需要通过内存来实现)作业会产生比较大的不利影响。所以如果某些字段会涉及到文件排序或者基于磁盘的临时表时,分配VARCHAR数据类型时仍然不能够太过于慷慨。还是要评估实际需要的长度,然后选择一个最长的字段来设置字符长度。如果为了考虑冗余,可以留10%左右的字符长度。千万不能认为其为根据实际长度来分配存储空间,而随意的分配长度,或者说干脆使用最大的字符长度。

举报

  • 相关推荐
  • 数据库就要选华为云!

    文章讲述了作者10年前创业失败的经历,反思当时过度投入高端服务器和技术架构,却忽视了业务实际需求。如今随着云计算、大数据等技术发展,数据库架构设计更强调弹性、可靠性和智能化。游戏行业作为典型高并发场景,对数据库提出实时响应、高可用等严苛要求。华为云TaurusDB作为新一代云原生数据库,具备高性能(QPS达百万级)、弹性扩展(1写15读节点)、高可靠性(跨区部署、RPO为0)等优势,完美适配游戏行业需求。其核心技术包括计算存储分离、并行执行和NDP近数据处理,解决了传统MySQL架构的复制延迟等问题。文章建议企业选择与业务协同成长的数据库平台,而非从零搭建架构。

  • 从“不敢替”到“能平替”:国产数据库如何逆袭Oracle核心腹地?

    文章讲述了一位资深数据库管理员老邓对国产数据库替代Oracle的担忧与转变。老邓最初对国产数据库持怀疑态度,担心应用改造难度大、数据迁移复杂、系统停机时间长等问题。但在技术选型会上,一家国产数据库厂商展示了六大核心解决方案:高兼容性实现零改造、全自动迁移工具确保数据一致性、柔性迁移方案避免停机、基于真实负载的测试工具、双轨并行随时回退机制,以及媲美Oracle的性能表现。最终老邓被金仓数据库的技术实力所折服,项目成功上线运行稳定。文章展现了国产数据库在核心技术上的突破,能够满足关键业务系统的替代需求。

  • 后信创时代,融合数据库成为国产数据库的新锚点

    7月15日,中电科金仓发布四款AI时代数据库核心产品:KES V92025融合数据库、KEMCC统一管控平台、云数据库一体机(AI版)和KFS Ultra智能数据集成平台。公司提出"融合数据库"战略,通过底层架构重构实现多模态数据统一处理,支持向量检索、语义计算等AI场景需求。金仓同步启动"金兰组织2.0"计划,联合产学研力量构建国产数据库生态。此次发布标志着国产数据库从"替代兼容"转向"定义未来",在AI驱动的技术变革中与国际厂商同步起跑。预计到2028年,中国数据库市场规模将达930亿元,年复合增长率12.23%。

  • 赛迪顾问:中国数据库市场达371.6亿,核心业务系统需求释放

    2024年全球数据库管理系统(DBMS)市场规模达627.3亿美元,中国市场规模达371.6亿元,占平台软件市场的42.1%。报告显示国产数据库厂商市场份额持续提升,电科金仓在关键应用领域销售套数保持第一,并在医疗与交通行业位居中国厂商销量首位。随着政策引导和技术创新,国产数据库正加速渗透核心业务系统,事务型数据库领域增长显著。未来三年行业信息化进程将提速,预计2027年中国数据库市场规模将达518.8亿元。国产数据库正从"替代"走向体系化创新,在AI等新技术驱动下重构技术版图。

  • CleanMyMac上线云存储清理功能

    CleanMyMac推出全新"云存储清理"功能,支持iCloud和OneDrive两大主流云服务。该功能提供统一可视化界面,可批量删除云端和本地的重复文件,或仅解除同步保留云端文件。通过滚动列表和可视化图谱两种模式,帮助用户高效管理存储空间。所有操作均在本地完成,确保数据安全。软件提供7天免费试用,并推出Basic基础版和Plus高级版两种套餐,现有用户可免费升级体验Plus全部功能。未来计划支持腾讯云、百度云等中国本土云平台,持续优化Mac存储管理体验。

  • 深信服超融合智能运维实战|数据库卡慢处置的一次关键事件

    西南某线缆制造企业基于深信服超融合平台运行Oracle RAC数据库,面临业务扩展期IT运维人力紧张、预算有限且缺乏专业DBA的困境。企业部署了400核CPU、6TB内存资源,运行120+台虚拟机承载OA、财务、生产管理、ERP等核心系统。主要问题包括:数据库性能监控不足,频繁出现卡慢现象;内存不足导致大量使用Swap,SGA缓存命中率仅67%;PGA内存消耗达上限。通过智能运维服务诊断发现系统内存配置不合理,建议方案包括:扩容虚拟机内存至220GB以上;配置大页内存;调整数据库文件系统IO策略为direct I/O;优化SGA为160G、PGA为20G。实施后数据库性能显著提升,运维效率提高60%以上,故障修复时间缩短50%。该案例展示了智能运维在资源优化、性能诊断方面的价值,助力企业突破传统运维困境。

  • WEEX亮相里约热内卢Blockchain.RIO:以社区为核心驱动全球化进程

    拉美地区Web3盛会Blockchain.RIO在巴西里约热内卢成功举办,WEEX交易所作为铂金赞助商亮相。WEEX首席运营官Andrew发表主题演讲,重点介绍WXT经济设计理念和平台生态发展战略,强调"流动性建设与平台生态发展"的运营思路。此次活动标志着WEEX全球化战略在拉美市场的深化推进,通过"技术稳健、社区参与、合规发展"三位一体策略构建品牌竞争力。WEEX将持续强化本地�

  • AI CRM如何跨越落地鸿沟?场景驱动与数据闭环成关键

    销售易发布中国首款AI CRM产品NeoAgent,标志着CRM行业进入智能化变革。该产品基于腾讯混元大模型+DeepSeek开源模型,提供多场景智能解决方案。AI CRM的核心价值在于数据驱动,通过构建统一客户数据平台,实现销售全流程智能化。目前已在客户服务、销售助理等场景落地,其中销售助理Agent可提升70%事务性工作效率。企业应用AI需关注数据基础与场景适配性,销售易通过"场景需求-产品供给-使用反馈-快速迭代"的闭环模式,推动AI CRM持续进化。在Agentic AI时代,数据能力成为企业智能化转型的关键竞争力。

  • 迄今最先进的AI模型!ChatGPT-5具备博士级别的认知能力

    ChatGPT-5在多个领域表现出色,包括编程、数学、写作、健康和视觉感知等。 它具备增强的推理能力,能够根据对话类型选择最佳模型,并通过深度推理模型解决更具挑战性的问题。 OpenAI 表示,ChatGPT-5在知识工作方面表现卓越,其知识水平在40多种职业中均达到或超过专家水平,涵盖法律、物流、销售和工程等领域。 在基准测试中,ChatGPT-5 展现了出色的认知能力。 例如,�

  • 告别“数据录入机器”:ToB智能体如何让CRM回归业务本质

    2025年腾讯全球数字生态大会上,销售易推出首款AI CRM产品NeoAgent,基于大模型技术重构企业销售流程。该产品通过语音指令自动完成客户拜访规划、关联历史数据并生成策略建议,实现从菜单点击到自然对话的交互变革。销售易通过"三阶跃迁"模式:解放双手的语音转结构化记录、突破菜单层级的智能检索、结合销售方法论的场景赋能,深度重构CRM系统。产品依托统一数据平台,实现多模态信息整合与权限管控,采用混合模型架构平衡响应速度与决策质量。目前已在米其林等企业应用中显著提升销售转化率,并通过"用户+流量"混合收费模式验证商业化路径。这标志着ToB领域AI正从效率工具向"数字同事"进化,其核心价值在于理解业务、适配场景并创造增量。