大家好,我是G探险者!
在开发过程中,我们经常遇到这样的灵异现象:明明数据库字段设置为 VARCHAR(1000),前端校验也限制了 1000 个字,但用户提交时后端却报错:"Data too long"。
这并非因为数据库坏了,而是因为不同的数据库对**"长度(Length)"**的定义完全不同。有的按"人眼看到的字"算,有的按"计算机存储的字节"算。
本文将横向对比主流数据库(MySQL, Oracle, SQL Server, PostgreSQL, 达梦)的字段长度表现,并给出避坑建议。
一、 核心预备知识:字符 vs 字节
在讨论数据库之前,必须先明确"汇率"问题。在最常用的 UTF-8 编码下:
- 1 个英文字符 = 1 字节
- 1 个数字 = 1 字节
- 1 个普通汉字 = 3 字节 (常见)
- 1 个 Emoji 表情/生僻字 = 4 字节
误区:很多老系统使用 GBK 编码,GBK 下 1 个汉字 = 2 字节。但现在互联网应用绝大多数使用 UTF-8。
二、 主流数据库大盘点
1. MySQL (5.0及以上版本)
- 定义单位 :字符 (Character)
- 表现 :
VARCHAR(1000)= 1000 个字符 。- 你可以存 1000 个 'A'。
- 也可以存 1000 个 '中'。
- 结论:MySQL 是最符合人类直觉的。如果报错,通常是因为包含 Emoji(需要 utf8mb4)或者富文本标签占用了额外长度。
2. Oracle
- 定义单位 :默认是 字节 (Byte)
- 表现 :
VARCHAR2(1000)= 1000 个字节 。- 存英文:可以存 1000 个。
- 存汉字(UTF-8):只能存约 333 个( <math xmlns="http://www.w3.org/1998/Math/MathML"> 1000 ÷ 3 1000 \div 3 </math>1000÷3)。
- 特殊情况 :如果在定义时显式写为
VARCHAR2(1000 CHAR),则按字符算。但在很多公司规范中,默认不加 CHAR,即按字节算。 - 常见报错 :
ORA-12899: value too large for column。
3. SQL Server
- 情况比较特殊,分为两类字段 :
VARCHAR(1000):字节(且仅支持非 Unicode)。存中文极易乱码或出错。NVARCHAR(1000):字符。
- 表现 :
NVARCHAR(1000)= 1000 个字符(无论中英文)。
- 结论 :在 SQL Server 中存中文,必须 使用
NVARCHAR,长度就是字数。
4. PostgreSQL
- 定义单位 :字符 (Character)
- 表现 :与 MySQL 类似,
VARCHAR(1000)= 1000 个字符。 - 特点 :PG 对文本长度非常宽容,底层机制使得
TEXT和VARCHAR性能差异极小,很多 PG 开发者习惯直接用TEXT。
5. 达梦数据库 (Dameng / DM)
- 定义单位 :取决于初始化参数
LENGTH_IN_CHAR。- 默认情况 (0) :按 字节 算。
VARCHAR(1000)<math xmlns="http://www.w3.org/1998/Math/MathML"> ≈ \approx </math>≈ 333 个汉字。 - 修改配置后 (1) :按 字符 算。
VARCHAR(1000)= 1000 个汉字。
- 默认情况 (0) :按 字节 算。
- 现状:绝大多数生产环境安装时都保持默认值(按字节),因此达梦是"存不够字"问题的重灾区。
三、 横向对比速查表
假设我们需要存储 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 或 达梦(默认配置),且前端限制用户输入 <math xmlns="http://www.w3.org/1998/Math/MathML"> N N </math>N 个字,数据库字段长度建议设置为 <math xmlns="http://www.w3.org/1998/Math/MathML"> N × 3 N \times 3 </math>N×3 甚至 <math xmlns="http://www.w3.org/1998/Math/MathML"> N × 4 N \times 4 </math>N×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)
- MySQL/PG :
-
前端截断机制 无论数据库存多大,前端在提交数据前,务必计算字符串长度。
- 注意 :如果后端按字节限制(如 Oracle),前端校验最好也写一个
lengthInBytes函数来计算,而不仅仅是string.length。
- 注意 :如果后端按字节限制(如 Oracle),前端校验最好也写一个
总结
- MySQL / PG / SQL Server(NVARCHAR):你说多少就是多少。
- Oracle / 达梦:你说多少,还要看看它每个字"有多重"(占多少字节)。