在Oracle数据库设计里，字符类型字段的选择直接影响存储效率与查询准确性。VARCHAR2和CHAR虽然都用来存字符串，但底层机制和适用场景差异很大。不少线上系统的模糊查询失效、关联漏数据，根源就是误用了这两种类型。下面从存储、比较、使用场景几个维度把它们的区别讲清楚。
一、存储机制与空间占用的本质不同
CHAR是定长字符类型，定义时需要指定长度，例如CHAR(10)。无论你插入的字符串实际有几个字符，Oracle都会占用10个字符位的空间，不足部分用空格补齐。这种机制意味着，哪怕你只存了一个字母A，磁盘上依然写了10个长度的单位。在单字节字符集下就是10字节，在多字节字符集里则按字符最大宽度计算。它的好处是行记录长度固定，更新时不容易产生行链接或行迁移。
VARCHAR2是变长类型，同样定义VARCHAR2(10)，插入A就只占1个字符位，加上Oracle内部的行头长度标识，总体远小于CHAR。它不会补空格，真实存什么就落盘什么。当字段长度波动大，比如用户名、地址、备注，用VARCHAR2能显著节省表空间和缓冲池内存。不过因为长度不定，对已有行做扩长更新可能让单行超出原数据块剩余空间，从而触发行迁移，对高频更新表要留意这个副作用。
从数据块结构看，CHAR的定长特性让全表扫描时的偏移计算非常快，数据库无需逐个解析长度；VARCHAR2则要在每行读取时先取长度字节再读内容。这种细微差别在超大表顺序扫描时可能体现为百分之几的CPU差异，但通常远小于错误类型导致的逻辑bug代价。建表时不能只算空间账，还要算正确率账。
二、比较规则与空格处理的隐蔽陷阱
最容易被忽略的是二者在等值比较时的行为。CHAR字段存'AB'进CHAR(5)，实际值是'AB '（尾部三个空格）。当用WHERE col = 'AB'查询时，Oracle会对字面量也补空格到5位再比，所以能匹配。但若是CHAR和VARCHAR2混用关联，比如CHAR列关联VARCHAR2列，VARCHAR2侧的'AB'没有空格，CHAR侧有空格，直接等值就可能不匹配，必须显式TRIM或RPAD对齐。
看一段容易出错的代码：
-- 建表
CREATE TABLE t_char (c CHAR(5));
CREATE TABLE t_vc (v VARCHAR2(5));
INSERT INTO t_char VALUES ('AB');
INSERT INTO t_vc VALUES ('AB');
-- 关联查询，可能无结果
SELECT * FROM t_char, t_vc WHERE c = v;
-- 正确写法
SELECT * FROM t_char, t_vc WHERE TRIM(c) = v;
上述例子中，未加TRIM的关联在多数版本下返回空，因为CHAR列带空格而VARCHAR2不带。这种问题在测试环境用小数据不易发现，上了生产关联丢失数据才暴露。另外在唯一约束上，CHAR列存'A'和'A '会被视为相同，而VARCHAR2列则视为不同，这也是设计权限编码或状态码字段时要先定死类型的理由。
空字符串在Oracle里也值得提一句：VARCHAR2的空串''等价于NULL，而CHAR(0)虽合法但极少用。对NULL的运算二者一致，但CHAR补空格逻辑不改变NULL语义。写应用层代码时，不要假设CHAR字段绝对非空，依然要做NULL判断。
三、索引效率与适用场景的实战建议
在索引层面，CHAR定长让B树索引键值整齐，页分裂略可控；VARCHAR2变长索引在插入随机长度值时可能产生更多碎页。但对于选择性高且长度差异大的列，VARCHAR2索引因键短反而树高更低，范围扫描更快。没有绝对优劣，要看数据分布。若字段是固定长度的国家码、性别标识、MD5前几位，用CHAR更直观且避免补空格烦恼；若字段是留言、标题、JSON片段，VARCHAR2是唯一合理选择。
给出建表参考：
-- 固定长度状态码用CHAR CREATE TABLE orders ( order_id NUMBER, status CHAR(2), -- 如 '01','02' remark VARCHAR2(200) ); -- 查询时无需TRIM SELECT * FROM orders WHERE status = '01';
上例中status用CHAR(2)，应用端统一写两位字符串，查询直白。remark用VARCHAR2存变长备注，省空间。若反向把status设成VARCHAR2(2)，虽也能跑，但团队里有人写'1'有人写'01'就会出乱子，定长类型从约束上逼着规范输入。最后提醒，从Oracle 12c起有了VARCHAR2扩容到32767字节的参数，但CHAR上限仍是2000字节，超长定长需求本就不该用CHAR。
综合来看，选类型先问自己：这列长度固定吗？会和别的类型关联吗？要不要唯一约束？回答清楚再落DDL，比事后修数据轻松得多。