我们知道，在Salesforce中，Number型的字段，整数位数与小数位数加一起，最多18位。
如果我们不要小数位，则可以存放18位整数。(18, 0)
假设这个整数为123,456,789,012,345,678的话，
来，跟我一起念，
十二京三千四百五十六兆七千八百九十亿一千一百二十三万四千五百六十七
这数字有多大，很大。
接下来，我们在画面输入这个数字。
然后在Developer Console里查询一下这个字段会发生什么呢？
咦？最后两位怎么回事？
好吧，我们在where语句里加一个条件，看看到底数据库里存的数字到底是多少。
Unknown error parsing query？解析query出错了？
马上拿去咨询了大神一下，大神淡淡的回答道：“加个.0”。
果然加.0就可以了！
这里推测是SFDC的SOQL解析器的锅。
我猜SFDC的SOQL解析器是这么处理的——————————
解析器在拿到字符串”123456789012345678″之后，
首先找一下包不包含小数点。
如果不包含小数点，则放到int里，
包含小数点，则放到double里。
由于SFDC里的Integer与JAVA里Int的最大值(INT_MAX)一样，都为2,147,483,647。
所以String to Int失败。
下面我们来验证一下这个脑洞，如果确实是遇到不带小数点的数字就放int里，那么理论上2,147,483,648就也会报同样的错误。
而2,147,483,647则不会报错。
脑洞证实。
所以当number字段里的值大于INT_MAX的时候，我们不得不手动加一个.0来告诉解析器，“把我放double里，谢谢。”
不过在Apex里倒是应该不会出现这个问题，因为你要查询一个大于INT_MAX的数字，首先就不能用Integer型的变量。。。
那么，Unknown error parsing query问题解决之后，我们也发现虽然查询结果显示的是123456789012345680，但仍然需要使用123456789012345678进行检索。这是怎么回事呢？
我换了一个工具进行检索。
原来由于位数太大，被科学计数了。
总之。虽然某些国家的货币金额之类的可能数字比较大，但能应用到这么多位数的情景应该不多，
能用其他类型就尽量使用其他类型，以免掉坑。