【 TiDB 使用环境】生产环境
【 TiDB 版本】v7.5
【遇到的问题】前期项目上线过程中，对于Oracle中的number(n,0)都会手工转换为decimal(n,0)。但是近期项目使用了tms，自动将oracle的number(n,0)的字段转换成了bigint(n,0)。请问，字段类型变成bigint(n,0)后java代码是否需要调整？如果不调整的话会有什么影响？
更新下最新进展，程序端验证出如下报错，还是要将bigint转为decimal才能解决。
java.lang.ClassCastException: java.math.BigInteger cannot be cast to java.math.BigDecimal
java代码用什么类型接受的这个字段呢？
如果是long，我感觉可以不用改，java的long类型和带符号bigint的范围是一致的。无符号的bigint有可能会溢出。
https://docs.pingcap.com/zh/tidb/stable/data-type-numeric#bigint-类型
BIGINT 在Java中通常对应于long 类型，这是一个64位的整数类型。然而，NUMBER(n,0) 在Java中可能被映射为Integer 、Long 或BigDecimal ，这取决于其精度。如果n 的值小于10，它可能被映射为Integer ；如果n 的值在10到18之间，它可能被映射为Long ；如果n 的值大于18，或者没有指定精度，它通常被映射为BigDecimal
如果TMS将NUMBER(n,0)转换为BIGINT(n,0)，并且你的Java代码中原本是使用BigDecimal来处理这些值的，如果你的代码中使用了BigDecimal，但现在字段变成了BIGINT，你可能需要将这些字段转换为long类型。这可能涉及到修改代码中的类型转换逻辑。
开发那边反馈，用什么类型的都有。Integer 、Long、BigDecimal都用到了。
请问，如果数据库内是bigint，代码中用BigDecimal接收数据，或者执行带有绑定变量的SQL传入了BigDecimal类型的数据，会有什么隐患吗？数字长度是固定死的，暂时不会发生越界的问题。Oracle处理传值字段类型不一致的时候会出现执行计划无法共享的问题，引发version count高导致share pool占用率高，不知道tidb会不会也出现类似的问题？
integer怕是不太保险，这个要看下具体的字段长度。long和BigDecimal是没问题的。
字段类型不一致，可能导致一些join需要隐式转换，用不上索引。别的好像也就没啥了。
整数应该没啥问题，小数问题就肯定数据不能完全对上了
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。
