MySQL和Oracle的CHAR、VARCHAR类型对比

在实际开发过程中，是否不确定字符类字段在数据库中设置多大合适，设置哪种类型，比如支持输入30个中文的地址字段。

CHAR与VARCHAR的区别

可变长度与不可变长度的区别。
CHAR(n)：固定长度，存储时会在尾部添加空格，查询时去掉尾部空格。
VARCHAR(n)：可变长度，存储时保留尾部空格，查询时也会原样返回（不会截断）。仅占用实际字符长度 + 1-2字节的长度标识（用于记录字符串实际长度），不会填充额外字符

类型	适合场景	典型例子
CHAR	长度固定、短字符串、查询频繁	手机号（11位）、性别（1-2字符）、邮编（6位）
VARCHAR	长度不固定、差异大、节省空间	用户名（3-20字符）、地址、商品描述、备注

优先根据数据长度是否固定--------固定长度用CHAR(性能优先)，可变长度用VARCHAR(空间优先)。

MySQL中的CHAR与VARCHAR

MySQL中的CHAR/VARCHAR默认按“字符数”定义长度。

1. CHAR类型（固定长度，不足补空格）
   CHAR(n)中的n是字符数（5.0.3+），无论英文还是中文，最多存储n个字符（仅受字符集是否支持中文影响）
   若编码格式为utf8，占3n字节
   若编码格式为utf8mb4（MySQL特有），占4n字节
2. VARCHAR类型（可变长度，仅存实际字符）

Oracle中的CHAR和VARCHAR2

Oracle推荐用VARCHAR2（VARCHAR已废弃），且长度定义支持显示指定BYTE(字节)或CHAR(字符)，默认值由参数NLS_LENGTH_SEMANTICS决定（11g前默认BYTE，11g后默认CHAR）。

1. NLS_LENGTH_SEMANTICS=BYTE，占n字节，最多存n个字节。
2. NLS_LENGTH_SEMANTICS=CHAR，最多存n个字符。所能存储的最大字节数，由数据库所设定的字符编码来定。

1. CHAR类型（固定长度，不足补空格）
   CHAR(n BYTE)或CHAR(n CHAR)，n分别代表“字节数”或“字符数”。
   a. CHAR(n CHAR)是存储中文的推荐方式，字符数与英文一致；
           若字符编码格式为UTF-8，占3n字节
           若字符编码格式为AL32UTF8（Oracle特有），占4n字节
   b. CHAR(n BYTE)需按中文字节数折算，存储量更少。
2. VARCHAR2类型（可变长度，无补空格）

字符编码与字符集

其实在上面问题中，涉及字符编码问题。在开发过程中，常常会看到UTF-8、GBK、Unicode等。这些概念，特别容易混淆。（有些场景也将下面表格中的ASCII、GBK、UTF-8等编码方式说是字符集，无需纠结，理解含义即可）

类型	代表	本质含义
字符集	Unicode	定义了全球所有语言字符（文字、符号、emoji等）的集合及唯一编号（码点）
编码方式	ASCII、GBK、UTF-8	规定如何将字符集中的字符等转化为计算机可存储的二进制码

为什么会有乱码？

乱码的本质是编码与解码方式不匹配。

例如：用GBK编码的“中”字（二进制DXD6D0），若用UTF-8解码，会解析为错误的字符，导致乱码。

解决方案：系统中统一使用UFT-8编码（全球化场景）或GBK（纯中文场景）。

维度	ASCII	GBK	UTF-8
类型	编码方式	编码方式	编码方式
字符覆盖范围	仅英文及基础符号 共128个字符（0-127），包括大小写字母、数字、标点和控制字符（如换行）	中日韩等东亚字符	全球所有字符
中文编码长度	不支持中文	2字节	通常3字节
兼容性	无依赖	兼容ASCII	兼容ASCII
应用场景	早起英文系统	中文Windows系统	互联网、跨语言系统

在MySQL中，支持utf8(即utf8mb3)和utf8mb4(大家可以查看mysql中新建数据库，选择字符集时，其中有utf8(即utf8mb3)、utf8mb4选项)

维度	utf8(即utf8mb3)	uftbmb4
支持的字符范围	仅支持1-3字节Unicode字符(如中文、英文)（中文字符占3字节，英文字符占1字节）	1-4字节的所有Unicode字符(含emoji、罕见字符)（中文字符占3字节，英文字符占1字节，emoji、生僻字占4字节）
存储占用	每个字符最多占3字节	每个字符最多占4字节
兼容性	与旧版本MySQL兼容	需MySQL5.5.3及以上版本支持
对emoji的支持	不支持(会显示为？或截断)	完全兼容
与标准的utf8的关系	子集(不完整实现)	完全符合标准