这其实不是异常行为，而是不同工具对数值精度的处理逻辑差异导致的，咱们来拆解清楚：

1. Oracle存储的本质 #

你定义的NUMBER(18,3)类型，意味着这个字段会精确存储小数点后3位的数值。你插入的123.123在Oracle中是完全按这个精度存储的，没有多余的零，数值本身是准确的。

2. SQL Developer的显示优化 #

SQL Developer为了让输出更友好，做了UI层面的格式化：它会自动省略小数点后末尾无意义的零。所以存储的123.123会被显示为123.123，而不是带多余零的格式——这只是展示效果，不代表存储的数值精度有变化。

3. ODP.NET的读取逻辑 #

当你用OracleDataReader读取这个字段时，默认会将其映射为C#的Decimal类型。Decimal类型会完整保留数值的精度元数据，包括字段定义的小数位数（这里是3位）。那为什么你会看到123.1230？

• 一种可能是你在调试窗口或者输出时，使用了默认的字符串格式化，某些场景下Decimal的默认输出会补零到特定的小数位数；
• 另一种情况是，ODP.NET的某些版本在处理NUMBER类型时，会根据Oracle内部的存储细节来设置Decimal的Scale，但无论如何，123.123和123.1230在数值上是完全相等的：

  decimal valFromDb = reader.GetDecimal(0);
  Console.WriteLine(valFromDb == 123.123m); // 输出 True
  

解决办法：让显示和SQL Developer一致 #

如果你希望在C#中得到和SQL Developer一样的简洁显示效果，可以通过格式化字符串来处理：

decimal value = reader.GetDecimal(0);
// 方法1：自动去掉末尾无意义的零
string formattedValue = value.ToString("G"); 
// 方法2：强制保留最多3位小数，去掉末尾零
string formattedValue2 = value.ToString("#.###");

这样处理后，输出就会和SQL Developer显示的123.123一致了。

内容的提问来源于stack exchange，提问作者Xie Steven