Oracle整数存储机制及ID列最优类型选型问询

1. 关于Oracle NUMBER类型存储逻辑的认知确认 #

你对「定点数存储整数相比原生整数效率更低」的认知基本正确，不存在核心疏漏：

• Oracle表列层面的NUMBER类型底层为变长十进制存储格式，每字节存储2位十进制数字，额外存储长度、符号位元数据，不存在将NUMBER(precision, 0)这类整数值转换为原生二进制标量整数存储的底层优化
• PL/SQL 中的BINARY_INTEGER、PLS_INTEGER等原生二进制整数类型仅支持在存储过程/函数的内存运算中使用，无法作为表列数据类型落地存储
• 以NUMBER(19,0)为例，存储最大值时占用约10字节存储空间，相比PostgreSQL的bigint固定8字节占用更高；运算时需要做十进制转二进制的额外计算，效率远低于CPU原生支持的整数运算

2. AWS SCT转换规则的优化建议 #

针对NUMBER(19,0)类型ID列 #

SCT默认转换为NUMERIC(19,0)是为了100%兼容Oracle的取值范围，但如果你可以确认所有ID值均为正整数且不超过9223372036854775807（64位有符号整数最大值，刚好覆盖19位正整数的常用区间），可以手动修改转换规则映射为bigint类型，存储空间、索引大小、查询效率都会有明显提升。

针对未指定精度的NUMBER类型 #

SCT默认转换为Double Precision的规则仅适用于原本存储浮点数值的场景，如果该列实际用于存储整数ID，绝对不能使用这个转换结果，否则会出现超过16位十进制数后的精度丢失问题，建议根据实际取值范围转换为int/bigint/NUMERIC类型。

3. Oracle普通ID列的最优数据类型 #

Oracle中存储整数ID的最优选择就是NUMBER(19,0)，原因如下：

• 取值范围覆盖所有常见业务ID、自增ID的需求，不会出现溢出问题
• 明确指定精度和标度，避免隐式转换带来的性能损耗和逻辑问题
• 完美兼容Oracle的序列、identity自增列特性
• 没有更高效的表级整数类型可选，这是Oracle当前架构下的最优解

注意不要使用无精度限制的NUMBER类型存储ID，除了前面提到的迁移风险外，还可能出现不必要的隐式转换，增加优化器判断成本。

内容的提问来源于stack exchange，提问作者David Kerr