背景
在一次需求开发中，采用UUID生成36个字符长度的唯一标识符作为ID，并将其存储于数据库中。在使用达梦数据库进行测试时，未遇到任何问题。然而，当我将环境切换至MySQL与PostgreSQL时，遇到了错误提示，指出ID长度超出限制。进一步检查后发现，问题出在ID字段的数据类型上，该字段被定义为VARCHAR(32)，显然无法容纳36个字符的UUID。
尽管达梦数据库同样接受并存储了这些超出长度的UUID，但实际上它对超出部分进行了自动截断处理。
排查
1. 初步猜测：字符集编码问题
起初，误以为问题出在不同数据库系统间字符集编码的差异上。曾遇到过MySQL因字符集和排序规则不匹配导致索引失效的情况。然而，深入研究后，发现字符集编码并非问题的根源。字符集编码主要是为了将各种符号——包括字母、数字、标点符号以及特殊字符——映射成计算机能够处理的二进制代码。
- ASCII：ASCII码主要用于英语字符的编码，包含128个字符。
- GBK/GB2312/GB18030：这些是中国国家标准，用于中文字符的编码。
- Unicode：包括UTF-8、UTF-16等编码格式，支持全球各种语言的字符，包括中文、日文、韩文等非拉丁字符。
- GB18030 主要针对中文字符进行了优化， UTF-8 是一种通用的国际化字符集编码。
2. 字符集长度单位的影响
| 字符集 | 长度单位 | varchar(1)所占字节数 | 一个汉字占用字节数 | 可以存储汉字数量 |
|---|---|---|---|---|
| utf8 | 字符 | 4 | 3 | 1 |
| utf8 | 字节 | 1 | 3 | 0 |
| GB18030 | 字符 | 2 | 2 | 1 |
| GB18030 | 字节 | 1 | 2 | 0 |
从上表可以看出，字符集编码和汉字所占的字节数相关，但这些与用户ID中的英文字母和数字无关。字符集长度单位的不同，导致了VARCHAR类型的字节数变化，而这直接影响到了用户ID的长度限制。经过仔细分析，发现达梦数据库是以字节为单位计算长度的，所以不是单位问题。
3. 达梦数据库的特殊行为
最后操作库，发现在id列输入超过32字节的数字之后保存，会自动消失，复制进去超过32字节的会自动截断。
以86结尾，在后面添加数字后保存发现还是以86结尾，在前面添加数字后发现数字会自动截断到32位。
问题根源
问题的根本原因在于：
- 字段长度定义不足：
VARCHAR(32)无法容纳36个字符的UUID。 - 数据库行为差异：
-
- MySQL和PostgreSQL严格执行字段长度限制，超出时会报错。
- 达梦数据库对超出部分进行了自动截断，导致问题被掩盖。
解决方案
1. 修改代码，缩短ID长度(选用）
由于表结构已经固定，最直接的解决方案是修改代码，将生成的UUID缩短至32个字符以内。例如，可以移除UUID中的连字符（-），将其从36个字符缩短为32个字符。
2. 使用数据库自增ID（常用）
如果不依赖UUID的唯一性，可以考虑使用数据库自增ID作为主键，避免手动生成ID带来的长度问题。
3. 修改表结构（一般不去修改表）
如果条件允许，可以修改表结构，将ID字段的长度扩展为VARCHAR(36)，以完全容纳UUID。
总结
本次问题的核心在于字段长度定义不足以及数据库行为差异。通过修改代码、优化表结构或使用自增ID，可以有效解决这一问题。同时，未来在开发中应更加注重数据库兼容性测试和字段设计的合理性，以避免类似问题的发生。
