别再死记英文报错了：KingbaseES 错误代码到底怎么读
不少从 Oracle、MySQL 转过来的开发，遇到 KingbaseES 报错，第一反应是看那行英文消息。其实官方手册里说得很明白：想知道发生了什么错误，应当查阅错误代码，而不是查看文本形式的错误消息。
为什么？因为错误代码比消息可靠得多。这篇聊聊 KingbaseES 错误代码这套体系。
错误代码长什么样
KingbaseES 沿用了 SQL 标准的 SQLSTATE 习惯，服务器发出的所有信息都有一个五位字符的错误代码。
比如：
42601—— 语法错误23505—— 违反唯一约束22007—— 无效的日期时间格式
代码分两段理解：
- 前两个字符：错误类别
- 后三个字符：该类别内的一种特定情况
所以哪怕你记不住具体代码，只看前两位也能判断大方向。比如 42 开头的都是语法/访问类问题，23 开头是约束违反类，22 开头是数据异常类。
为什么要看代码，而不是看消息
三个理由，都是实际开发中会遇到的：
1. 错误代码跨版本稳定
"在 KingbaseES 的版本之间，错误代码不会轻易改变"。你 9 版本写的异常处理逻辑，升到新版本大概率还能用。英文消息就不一定了，说不定措辞就改了。
2. 错误代码不受本地化影响
数据库可以配置不同的消息语言。同一个错误，中文环境报中文，英文环境报英文。你的程序如果按消息文本匹配，换个环境就废了。错误代码永远是那五个字符。
3. 未知代码也能推断
文档原话："那些不能识别特定错误代码的应用仍然可以从错误类别中推断要做什么。"前两位告诉你类别，就算没见过这个具体代码，也知道大概是什么类型的问题，该怎么处理。
代码从哪来
KingbaseES 的错误代码分几类来源：
- 部分由 SQL 标准定义（SQLSTATE 标准那套）
- 部分标准没定义的，由 KingbaseES 自己定义
- 部分从其它数据库借鉴而来
所以你会看到一些眼熟的代码——它们不是巧合，是生态兼容的设计。从别的数据库迁过来的应用，异常处理代码往往能直接复用。
程序里怎么用好错误代码
写应用时，捕获异常不要匹配消息文本，要匹配错误代码：
# 错误示范：匹配消息文本
except Exception as e:
if "unique constraint" in str(e):
...
# 正确示范：匹配错误代码
except Exception as e:
code = get_sqlstate(e) # 伪代码，实际按驱动 API 获取
if code == "23505":
...
常见要处理的代码提前列出来：
| 代码 | 含义 | 典型处理 |
|---|---|---|
| 23505 | 违反唯一约束 | 提示用户数据重复或重试 |
| 23503 | 违反外键约束 | 提示存在关联数据 |
| 42601 | 语法错误 | 检查 SQL 拼接 |
| 22P02 | 无效的文本表示 | 检查类型转换 |
| 40001 | 序列化失败 | 重试事务 |
| 57014 | 查询被取消（超时） | 优化 SQL 或调大超时 |
把错误代码映射表写进代码里，报错处理逻辑清晰又稳定。
运维排查也能用
DBA 排查问题时，日志里除了消息还有错误代码，按代码搜文档、搜社区案例，比按消息搜准确得多。同一个代码对应的根因通常一致，处理方案可以直接复用。
结尾
一句话总结：KingbaseES 的错误代码是跨版本、跨语言的稳定标识，程序判断和问题排查都应该以它为准，英文消息只当参考。
官方《KingbaseES 错误代码》手册里列出了全部代码和含义，建议存一份在团队文档里，开发写异常处理、运维排查问题时翻一翻，比临时百度靠谱。
