Oracle 字符类型
使用 VARCHAR2 (1 BYTE) 是否比使用 CHAR(1 BYTE) 效率低？
如果我从未在字段中放置超过一个字符的任何值，那么使用 VARCHAR2 (2000 BYTE) 是否比使用 CHAR(1 BYTE) 效率低？
** 所谓高效，是指在时间（搜索）和空间（存储）方面都高效。
Is using a VARCHAR2 (1 BYTE) any less efficient than using CHAR(1 BYTE)?
Is using a VARCHAR2 (2000 BYTE) any less efficient than using CHAR(1 BYTE), if I never put any value longer than one character in the field?
** By efficient, I meant efficient in both time (searching) and space (storing).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据您的字符集，CHAR(1 BYTE) 可能无法存储任何特定字符，因此如果我们讨论多字节字符，VARCHAR2(2000 BYTE) 和 CHAR(1 BYTE) 之间可能存在差异。
更一般地说，在 SQL 中（PL/SQL 规则有点不同），如果您只存储 1 个字节的数据，则 VARCHAR2(2000 BYTE) 不会比 CHAR(1 BYTE) 消耗更多的存储空间（我假设“高效”主要翻译为存储效率）。 VARCHAR2(2000 BYTE)经常会导致客户端应用程序分配2000字节的缓冲区来保存字段的内容，因为客户端应用程序事先不知道实际数据大小，这可能会导致客户端应用程序使用过多的数据。 RAM 量。 不过，这可能会也可能不会转化为真正的问题。 大多数客户端应用程序不会损害 RAM，并且大多数结果集不会向客户端返回数百万行，因此在几百行上浪费几 k 可能不是什么大问题。
有一个 AskTom 线程 更详细，特别是关于 PL/SQL 规则。
Depending on your character set, CHAR(1 BYTE) may not be able to store any particular character, so there may be differences between VARCHAR2(2000 BYTE) and CHAR(1 BYTE) if we're talking about multi-byte characters.
More generally, in SQL (the PL/SQL rules are a bit different) a VARCHAR2(2000 BYTE) isn't going to consume more storage than a CHAR(1 BYTE) if you are storing just 1 byte of data (I assume "efficient" translates primarily to storage efficiency). A VARCHAR2(2000 BYTE) will frequently cause a client application to allocate a 2000 byte buffer to hold the contents of the field, since the client application doesn't know the actual data size in advance, which may cause the client application to use excessive amounts of RAM. That may or may not translate into a real issue, though. Most client applications aren't hurting for RAM and most result sets aren't returning millions of rows to the client, so wasting a couple k on a couple hundred rows may not be a big deal.
There is an AskTom thread that goes into more detail, particularly regarding the PL/SQL rules.