那些年long与varchar碰撞的火花

事情是这个样子的，听我娓娓道来：

最近项目中数据库主键类型为 varchar，而项目中实体字段类型为 Long，项目中的id 是雪花算法生成的，众所周知，雪花算法生成的id一般是19位，这就导致了后续根据主键id查询的时候，结果集异常的情况（根据一个主键id查询数据，结果集是多条数据），这是什么原因导致的？

事情正解：

由于 varchar 对应的 Java 类型为 String，而项目中是 Long 类型，这就导致了 Long 类型的 id 和 库中的 varchar 类型作对比时，类型不匹配问题。当字符串与数值类型进行比较时，字符串和数值都会被装换为浮点类型进行比较。
字符串转换成浮点类型时，如果字符串开头是数字，那么会一直截取，直到截取的不是数字为止（例：“123abc”，会被截取为 “123”），当字符串开头不是数字时，那么转换数值类型的结果就是0（例：“abc123”，会被转换为“0”）

在我的项目中，19位类型为 varchar 的主键id 在转换成浮点类型时，由于数值太大，会用科学记数法表示，而且浮点数的精度不准确，都是近似取值，所以数值相近的都会被查询出来，导致了结果集为多条的“异常”现象。

所以如果数据库中使用了 varchar 类型，查询时不要使用数值类型去查询，要使用对应的 String 类型查询就不会出现这种“异常”现象了。

附一张数据库类型与Java类型对应表：