SQL中char、varchar、nvarchar的区别

本文详细介绍了SQL中的几种常见数据类型,包括char、varchar、nvarchar等的区别及应用场景,帮助读者理解如何选择合适的类型来提高数据库的性能。

char
    char是定长的,也就是当你输入的字符小于你指定的数目时,char(8),你输入的字符小于8时,它会再后面补空值。当你输入的字符大于指定的数时,它会截取超出的字符。
   nvarchar(n)
    包含 n 个字符的可变长度 Unicode 字符数据。
n 的值必须介于 1 与 4,000 之间。字节的存储大小是所输入字符个数的两倍。所输入的数据字符长度可以为零。      
varchar[(n)] 
    长度为 n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为输入数据的字节的实际长度,而不是 n 个字节。所输入的数据字符长度可以为零。
1、CHAR。CHAR存储定长数据很方便,CHAR字段上的索引效率级高,比如定义char(10),那么不论你存储的数据是否达到了10个字节,都要占去10个字节的空间。 

 2、VARCHAR。存储变长数据,但存储效率没有CHAR高。如果一个字段可能的值是不固定长度的,我们只知道它不可能超过10个字符,把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。为什么“+1”呢?这一个字节用于保存实际使用了多大的长度。 
从空间上考虑,用varchar合适;从效率上考虑,用char合适,关键是根据实际情况找到权衡点。 
3、TEXT。text存储可变长度的非Unicode数据,最大长度为2^31-1(2,147,483,647)个字符。 
4、NCHAR、NVARCHAR、NTEXT。这三种从名字上看比前面三种多了个“N”。它表示存储的是Unicode数据类型的字符。我们知道字符中,英文字符只需要一个字节存储就足够了,但汉字众多,需要两个字节存储,英文与汉字同时存在时容易造成混乱,Unicode字符集就是为了解决字符集这种不兼容的问题而产生的,它所有的字符都用两个字节表示,即英文字符也是用两个字节表示。nchar、nvarchar的长度是在1到4000之间。和char、varchar比较起来,nchar、nvarchar则最多存储4000个字符,不论是英文还是汉字;而char、varchar最多能存储8000个英文,4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字,较为方便,但在存储英文时数量上有些损失。 
所以一般来说,如果含有中文字符,用nchar/nvarchar,如果纯英文和数字,用char/varchar。

内容概要:本文详细介绍了“秒杀商城”微服务架构的设计与实战全过程,涵盖系统从需求分析、服务拆分、技术选型到核心功能开发、分布式事务处理、容器化部署及监控链路追踪的完整流程。重点解决了高并发场景下的超卖问题,采用Redis预减库存、消息队列削峰、数据库乐观锁等手段保障数据一致性,并通过Nacos实现服务注册发现与配置管理,利用Seata处理跨服务分布式事务,结合RabbitMQ实现异步下单,提升系统吞吐能力。同时,项目支持Docker Compose快速部署Kubernetes生产级编排,集成Sleuth+Zipkin链路追踪与Prometheus+Grafana监控体系,构建可观测性强的微服务系统。; 适合人群:具备Java基础Spring Boot开发经验,熟悉微服务基本概念的中高级研发人员,尤其是希望深入理解高并发系统设计、分布式事务、服务治理等核心技术的开发者;适合工作2-5年、有志于转型微服务或提升架构能力的工程师; 使用场景及目标:①学习如何基于Spring Cloud Alibaba构建完整的微服务项目;②掌握秒杀场景下高并发、超卖控制、异步化、削峰填谷等关键技术方案;③实践分布式事务(Seata)、服务熔断降级、链路追踪、统一配置中心等企业级中间件的应用;④完成从本地开发到容器化部署的全流程落地; 阅读建议:建议按照文档提供的七个阶段循序渐进地动手实践,重点关注秒杀流程设计、服务间通信机制、分布式事务实现系统性能优化部分,结合代码调试与监控工具深入理解各组件协作原理,真正掌握高并发微服务系统的构建能力。
# CHARVARCHAR 数据类型详解 在 SQL 建表语句中,CHAR VARCHAR 都是用于存储字符串的数据类型,但它们在存储方式性能特性上有重要区别: ## 主要区别 | 特性 | CHAR | VARCHAR | |---------------------|-------------------------------|------------------------------| | **存储方式** | 固定长度 | 可变长度 | | **存储空间** | 总是占用定义时的全长 | 仅占用实际数据长度+长度标识(1-2字节) | | **检索速度** | 通常更快 | 稍慢(需要计算实际长度) | | **尾部空格处理** | 自动填充空格到固定长度 | 保留原始长度,不填充空格 | | **最大长度** | MySQL 5.0.3+: 255字符 | MySQL: 65,535字节(受行大小限制) | | **适用场景** | 长度固定的数据(如国家代码) | 长度变化大的数据(如用户名) | ## 详细对比 ### 1. 存储机制 - **CHAR(N)**: - 存储时总是占用 N 个字符的空间 - 如果插入的数据长度小于 N,会用空格填充至 N 长度 - 检索时会去除尾部空格 ```sql CREATE TABLE char_test ( country_code CHAR(3) -- 总是占用3字符空间 ); ``` - **VARCHAR(N)**: - 存储时只占用实际数据长度 + 1或2字节的长度前缀 - 在 MySQL 5.0.3 之前,最大长度为 255 字符 - 之后版本最大可达 65,535 字节(受行大小限制) ```sql CREATE TABLE varchar_test ( username VARCHAR(50) -- 最多占用50字符+长度标识 ); ``` ### 2. 性能差异 - **CHAR**: - 读取速度更快(固定偏移量) - 适合短且长度固定的字符串 - 频繁更新的字段使用 CHAR 可减少碎片 - **VARCHAR**: - 节省存储空间(特别是长字符串) - 适合长度变化大的字符串 - 略微增加存储检索的开销(需要处理长度前缀) ### 3. 存储示例 假设存储字符串 "ABC": - 在 CHAR(10) 中: - 存储: "ABC " (7个空格填充) - 占用: 10 字符空间 - 在 VARCHAR(10) 中: - 存储: [3字节长度前缀]"ABC" - 占用: 实际4字节(1字节长度前缀+3字符) ## 使用建议 1. **使用 CHAR 的情况**: - MD5 哈希值(总是32字符) - 国家/地区代码(如'CN', 'US') - 性别('M'/'F') - Y/N 标志 - 短且长度固定的标识符 2. **使用 VARCHAR 的情况**: - 用户名、邮箱地址 - 产品描述 - 评论内容 - 任何长度变化大的文本 - 长度可能超过100字符的文本 ## 数据库特定实现 不同数据库系统对 CHAR VARCHAR 的实现有细微差别: - **MySQL/MariaDB**: - VARCHAR 最大长度受行大小限制(65,535字节总行大小) - 5.0.3 之前 VARCHAR 最大255字符 - **PostgreSQL**: - 没有 CHAR VARCHAR 的性能差异 - CHAR(n) VARCHAR(n) 在存储上几乎相同 - 提供 TEXT 类型用于大文本 - **SQL Server**: - CHAR VARCHAR 最大8,000字符 - 提供 VARCHAR(MAX) NVARCHAR(MAX) 用于大文本 - **Oracle**: - CHAR 总是填充到全长 - VARCHAR2 是推荐使用的可变长度类型(Oracle 建议不用 VARCHAR) ## 示例建表语句 ```sql CREATE TABLE user_profiles ( id INT PRIMARY KEY AUTO_INCREMENT, -- 固定长度字段使用CHAR country_code CHAR(2), -- ISO国家代码 gender CHAR(1), -- 'M'或'F' is_active CHAR(1), -- 'Y'或'N' -- 可变长度字段使用VARCHAR username VARCHAR(50) NOT NULL, email VARCHAR(255) NOT NULL, bio VARCHAR(1000), -- 个人简介 -- 创建时间使用固定长度格式 created_at CHAR(19) -- 存储'YYYY-MM-DD HH:MM:SS'格式 ); ``` ## 注意事项 1. 在 MySQL 中,如果启用了 `PAD_CHAR_TO_FULL_LENGTH` SQL 模式,CHAR 类型将保留尾部空格而不进行修剪 2. 对于非常长的字符串,考虑使用 TEXT 类型(MySQLVARCHAR TEXT 在存储方式上有区别,TEXT 有单独的存储区域) 3. 在排序比较操作中,CHAR VARCHAR 的行为可能不同,特别是在不同长度的字符串比较时 4. 索引效率:CHAR 列上的索引通常更紧凑,因为长度固定 5. 存储引擎影响:InnoDB MyISAM 对这些类型的处理可能略有不同
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值