【 TiDB 使用环境】生产环境
【 TiDB 版本】v7.5
【遇到的问题】前期项目上线过程中,对于Oracle中的number(n,0)都会手工转换为decimal(n,0)。但是近期项目使用了tms,自动将oracle的number(n,0)的字段转换成了bigint(n,0)。请问,字段类型变成bigint(n,0)后java代码是否需要调整?如果不调整的话会有什么影响?
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需要隐式转换,用不上索引。别的好像也就没啥了。