测试中发现的一个有趣的小问题！

测试中发现的一个小问题，感觉挺有趣记录一下！

问题描述：

在业务测试过程中，我们在mysql使用的一个字段值类型为int类型，然后再测试极值的情况下，我输入10个9发现可以正常提交数据并保存成功，然而当再次进入配置的时候发现保存的值并非10个9而是变为了1410065407。然后自己通过抓包发现在输入10个9保存提交的时候，接口传参是正常的而且接口也没有返回错误的信息，但是当进入数据库查看发现数据落库的时候并非10个9而是1410065407。

然后自己又输入了一个超出int类型范围的一个值：2147483648，发现提交的时候系统直接报错无法提交。那么为啥10个9可以提交成功而比它小的2147483648确提交失败呢？

有兴趣的大家可以先自己考虑一下是什么原因导致的，然后看是否和我确认的一样。

问题原因：
首先我们需要了解在MySQL中，INT是一种整数数据类型，它占用4个字节(32位)的存储空间。这意味着，INT数据类型可以表示32位的整数，其范围为-2,147,483,648到2,147,483,647。
当我们在输入2147483648 这个会报错 是因为4个字节内超过int32，不符合int32规范，所有点击保存提交数据的时候就直接报错了。
当我们输入10个9系统未报错，是因为10个9的值的后四个字节数同1410065407相同属于int合法范围内，所以可以配置成功（这种属于精度丢失）。
10个9换成二进制如下：
        1001010100000010111110001111111111，int占用4个字节，每个字节是8位也就是32位，我们取32位数即：10 01010100 00001011 11100011 11111111

 1410065407换成二进制如下：

        1010100000010111110001111111111，取32位即：1010100 00001011 11100011 11111111，最后一个缺以为补0也就是：01010100 00001011 11100011 11111111，同上面的取值相同

所以当我输入10个9未保存的原因是该值超过了int类型位数，导致精度丢失，但是该值的后32未确和int类型中 1410065407值一致且没有超出int类型范围，所以程序认为该值是合法的。