为什么 VARCHAR(1000) 存不了 1000 个汉字？ —— 详解主流数据库“字段长度”的底层差异大家好，我是G

大家好，我是G探险者！

在开发过程中，我们经常遇到这样的灵异现象：明明数据库字段设置为 VARCHAR(1000)，前端校验也限制了 1000 个字，但用户提交时后端却报错：“Data too long”。

这并非因为数据库坏了，而是因为不同的数据库对**“长度（Length）”**的定义完全不同。有的按“人眼看到的字”算，有的按“计算机存储的字节”算。

本文将横向对比主流数据库（MySQL, Oracle, SQL Server, PostgreSQL, 达梦）的字段长度表现，并给出避坑建议。

在讨论数据库之前，必须先明确“汇率”问题。在最常用的 UTF-8 编码下：

误区：很多老系统使用 GBK 编码，GBK 下 1 个汉字 = 2 字节。但现在互联网应用绝大多数使用 UTF-8。

定义单位：默认是 字节 (Byte)
表现：VARCHAR2(1000) = 1000 个字节。
- 存英文：可以存 1000 个。
- 存汉字（UTF-8）：只能存约 333 个（ $1000 \div 3$ ）。
特殊情况：如果在定义时显式写为 VARCHAR2(1000 CHAR)，则按字符算。但在很多公司规范中，默认不加 CHAR，即按字节算。
常见报错：ORA-12899: value too large for column。

情况比较特殊，分为两类字段：
- VARCHAR(1000)：字节（且仅支持非 Unicode）。存中文极易乱码或出错。
- NVARCHAR(1000)：字符。
表现：
- NVARCHAR(1000) = 1000 个字符（无论中英文）。
结论：在 SQL Server 中存中文，必须使用 NVARCHAR，长度就是字数。

定义单位：取决于初始化参数 LENGTH_IN_CHAR。
- 默认情况 (0)：按字节算。VARCHAR(1000) $\approx$ 333 个汉字。
- 修改配置后 (1)：按字符算。VARCHAR(1000) = 1000 个汉字。
现状：绝大多数生产环境安装时都保持默认值（按字节），因此达梦是“存不够字”问题的重灾区。

假设我们需要存储 1000 个汉字 (UTF-8编码)，各数据库字段该如何定义？

数据库类型	字段类型选择	定义长度 (N)	计算逻辑	备注
MySQL	VARCHAR	1000	按字符	最省心
PostgreSQL	VARCHAR	1000	按字符	同样省心
SQL Server	NVARCHAR	1000	按字符	必须带 N
Oracle	VARCHAR2	3000	按字节	需乘以 3 (推荐留余量至 4000)
Oracle (写法二)	VARCHAR2	1000 CHAR	按字符	需确认 DBA 是否允许
达梦 (默认)	VARCHAR	3000	按字节	同 Oracle，需乘以 3
达梦 (配置后)	VARCHAR	1000	按字符	需检查 `LENGTH_IN_CHAR=1`

为了避免上线后出现 Data too long 异常，建议遵循以下原则：

“乘以 3 再加点”原则 如果你的数据库是 Oracle 或达梦（默认配置），且前端限制用户输入 $N$ 个字，数据库字段长度建议设置为 $N \times 3$ 甚至 $N \times 4$ 。

例子：用户输入 1000 字，数据库设为 VARCHAR(3000) 或 VARCHAR(4000)。
警惕富文本编辑器 如果前端是一个富文本框（能加粗、变色、换行），用户虽然只看见 1000 个字，但实际传输的 HTML 代码（<span style="...">...</span>）可能长达 5000 字符。

对策：富文本字段直接使用 TEXT / CLOB / LONGTEXT 类型，不要用 VARCHAR。
统一使用 TEXT/CLOB 对于超过 2000 字的长文本，不要纠结于 VARCHAR 的具体长度，直接使用大文本类型：
- MySQL/PG: TEXT
- Oracle/达梦: CLOB (Character Large Object)
- SQL Server: NVARCHAR(MAX)
前端截断机制 无论数据库存多大，前端在提交数据前，务必计算字符串长度。
- 注意：如果后端按字节限制（如 Oracle），前端校验最好也写一个 lengthInBytes 函数来计算，而不仅仅是 string.length。

为什么 VARCHAR(1000) 存不了 1000 个汉字？ —— 详解主流数据库“字段长度”的底层差异